* Koehrer Mathias (ETAS/ESW5) | 2015-07-13 06:18:22 [+0000]:
>> if you managed to trigger it that reliably, could you revert
>> slub_delay_ctor_on_rt.patch in the queue and try again?
>>
>Over the weekend I ran a test that rebooted the PC permanently.
>After about 400 reboots I got another NULL pointer dereference.
>However the slub_delay_ctor_on_rt.patch has not been reverted yet.
>And: This looks somehow differently than the previous BUGs.
>
>
>[ 3.299329] BUG: unable to handle kernel NULL pointer dereference at 0000008c
>[ 3.299332] IP: [<c10df66c>] function_trace_call+0xc/0x190
This is
| static void
| function_trace_call(unsigned long ip, unsigned long parent_ip,
| struct ftrace_ops *op, struct pt_regs *pt_regs)
| {
| struct trace_array *tr = op->private;
|…
|
| if (unlikely(!tr->function_enabled))
| return;
and it looks like tr is null. BUG_ON(!tr) should prove this.
Steven, is it somehow possible that on module load we get "op" set
without its private member initialized?
Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
