* Koehrer Mathias (ETAS/ESW5) | 2015-07-13 06:18:22 [+0000]:

quoted

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