Re: BUG: unable to handle kernel NULL pointer dereference on 3.18.13-rt10

[Sebastian Andrzej Siewior <bigeasy@linutronix.de>]

* 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html