[Crash-utility] (no subject)

Dave Anderson anderson at redhat.com
Tue Dec 2 14:11:37 UTC 2014



----- Original Message -----
> 
> 
> Hi Dave,
> 
> 
> 
> I have been looking at the trace extension that you deliver together with
> crash. In the kernel I look at the trace_array is defined as:
> 
> 
> 
> struct trace_array {
> 
> struct list_head list;
> 
> char *name;
> 
> struct trace_buffer trace_buffer;
> 
> #ifdef CONFIG_TRACER_MAX_TRACE
> 
> /*
> 
> */
> 
> struct trace_buffer max_buffer;
> 
> bool allocated_snapshot;
> 
> #endif
> 
> ....
> 
> 
> 
> However trace.c assumes that if the trace_buffer field exists then the
> max_buffer field also exists, which is not true. So if
> CONFIG_TRACER_MAX_TRACE is not defined in the kernel then the trace
> extension will fail when it is loaded with a message that the max_buffer
> field does not exist.
> 
> To fix this then the statements:
> 
> init_offset(trace_array, max_buffer);
> 
> in the function init_offsets and
> 
> ftrace_int_max_tr_trace();
> 
> in function ftrace_init should not be executed if the max_buffer field is not
> present. I have tested this and it works for me.
> 
> Jan

Not knowing anything about this module, but looking at the code, I guess I don't
understand how/why ftrace_int_max_tr_trace() can be totally avoided?

But in any case, the trace.c extension module is maintained by Qiao Nuohan, so 
I've cc'd him.

Qiao, can you fix this issue and post a patch?

Thanks,
  Dave




More information about the Crash-utility mailing list