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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.00.0904211051590.10097@gandalf.stny.rr.com>
Date:	Tue, 21 Apr 2009 10:54:13 -0400 (EDT)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Ingo Molnar <mingo@...e.hu>
cc:	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Frédéric Weisbecker <fweisbec@...il.com>,
	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH][GIT PULL] ring-buffer: only warn on wrap if buffer is
 bigger than two pages




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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/