On Mon, 13 Jul 2015 11:12:37 +0200
Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx> wrote:
> * 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?
>
What's the test that was run, and how did it enable function tracing?
-- Steve
--
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
