Re: (no subject)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




----- 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

--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility




[Index of Archives]     [Fedora Development]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]

 

Powered by Linux