[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