Messages in this thread | | | Date | Wed, 09 Dec 2009 11:16:52 -0500 | From | Masami Hiramatsu <> | Subject | Re: [PATCH v3] [RFC] tracepoint: Add signal coredump tracepoint |
| |
Masami Hiramatsu wrote: > > > KOSAKI Motohiro wrote: >>> + TP_fast_assign( >>> + __entry->sig = (int)cprm->signr; >>> + __entry->limit = cprm->limit; >>> + __entry->flags = cprm->mm_flags; >>> + __entry->retval = retval; >>> + __assign_str(name, core_name); >>> + ), >>> + >>> + TP_printk("sig=%d limit=%lu dumpable=0x%lx dump_filter=0x%lx " >>> + "corename=\"%s\" retval=%d", >>> + __entry->sig, __entry->limit, >>> + __entry->flags& MMF_DUMPABLE_MASK, >>> + (__entry->flags& MMF_DUMP_FILTER_MASK)>> >>> + MMF_DUMP_FILTER_SHIFT, >>> + __get_str(name), __entry->retval) >>> +); >>> #endif /* _TRACE_SIGNAL_H */ >> >> I don't think "limit" is userfriendly name, core_limit or core_size_limit is better? >> plus, we have core_pipe_limit sysctl too. (it's similar but different concept limit). > > Ah, I missed it. OK, so I'll rename core_limit and add core_pipe_limit.
Hmm, perhaps, would we need a pair of core_pipe_limit and dump_count? because it limits the number of concurrently dump-to-pipe and the number is stored on dump_count. Or, maybe it is enough to trace current parameters, because if we hit the core_pipe_limit, we can see -EFBIG at retval parameter.
> Thank you for pointed it out :-) > >> >> other parts looks good to me. >> >> >> > > Thanks! >
-- Masami Hiramatsu
Software Engineer Hitachi Computer Products (America), Inc. Software Solutions Division
e-mail: mhiramat@redhat.com
| |