Re: [PATCH][GIT PULL] ring-buffer: only warn on wrap if buffer is bigger than two pages

[Steven Rostedt <rostedt@goodmis.org>]

On Tue, 21 Apr 2009, Ingo Molnar wrote:

> 
> here's a new one:
> 
>  Testing event sched_kthread_stop: <4>------------[ cut here ]------------
>  WARNING: at kernel/fork.c:988 copy_process+0x147/0xf7d()
>  Modules linked in:
> 
> config attached, bootlog below. This warning has the signs of some 
> sort of lockdep interaction. (this too is a new one - it never 
> triggered before)
> 
> 	Ingo
> 
> Running tests again, along with the function tracer
> Running tests on trace events:
> Testing event kfree_skb: OK
> Testing event kmalloc: OK
> Testing event kmem_cache_alloc: OK
> Testing event kmalloc_node: OK
> Testing event kmem_cache_alloc_node: OK
> Testing event kfree: OK
> Testing event kmem_cache_free: OK
> Testing event irq_handler_exit: OK
> Testing event irq_handler_entry: OK
> Testing event softirq_entry: OK
> Testing event softirq_exit: OK
> Testing event lock_acquired: OK
> Testing event lock_acquire: OK
> Testing event lock_release: OK
> Testing event lock_contended: OK
> Testing event sched_kthread_stop: <4>------------[ cut here ]------------
> WARNING: at kernel/fork.c:988 copy_process+0x147/0xf7d()
> Modules linked in:
> Pid: 2, comm: kthreadd Not tainted 2.6.30-rc2-tip-01581-gf4879a9-dirty #34509
> Call Trace:
>  [<ffffffff80249801>] warn_slowpath+0x96/0xca
>  [<ffffffff8026f200>] ? trace_hardirqs_on_caller+0xff/0x14c
>  [<ffffffff8026f25a>] ? trace_hardirqs_on+0xd/0xf
>  [<ffffffff80261cb6>] ? __mutex_init+0x5a/0x64
>  [<ffffffff802accdf>] ? perf_counter_init_task+0x65/0x17b
>  [<ffffffff80247ca6>] copy_process+0x147/0xf7d
>  [<ffffffff80211d57>] ? trace+0x3a/0x73
>  [<ffffffff80248c7b>] do_fork+0x19f/0x478
>  [<ffffffff8025f03c>] ? kthreadd+0xb8/0x11c
>  [<ffffffff80212f12>] kernel_thread+0x82/0xe0
>  [<ffffffff808cbad4>] ? schedule+0x11f/0x5e1
>  [<ffffffff8025f0a0>] ? kthread+0x0/0x80
>  [<ffffffff80212f70>] ? child_rip+0x0/0x20
>  [<ffffffff8025f050>] ? kthreadd+0xcc/0x11c
>  [<ffffffff80fde140>] ? early_idt_handler+0x0/0x71
>  [<ffffffff80212f7a>] child_rip+0xa/0x20
>  [<ffffffff80212a52>] ? restore_args+0x0/0x30
>  [<ffffffff8025ef84>] ? kthreadd+0x0/0x11c
>  [<ffffffff80212f70>] ? child_rip+0x0/0x20
> ---[ end trace 0843ba422c5d704e ]---
> OK
> Testing event sched_kthread_stop_ret: OK

The above looks like the tracer slowed things down enough to trigger a 
race elsewhere.

We have function tracing happening, and here we enabled the 
sched_kthread_stop tracepoint. Each test starts and stops a kernel thread. 

I'm not sure how this could have triggered.

I'll investigate a little more.

-- Steve