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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAADnVQJSvFeqRT+x3y5AWOC396nOdZQ4Zf66Es-71PxBtpj_GA@mail.gmail.com>
Date: Thu, 14 Dec 2023 17:59:36 -0800
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: bpf <bpf@...r.kernel.org>, Network Development <netdev@...r.kernel.org>, 
	LKML <linux-kernel@...r.kernel.org>, "Paul E. McKenney" <paulmck@...nel.org>, 
	Stephen Rothwell <sfr@...b.auug.org.au>, Alexander Potapenko <glider@...gle.com>, 
	Andrey Konovalov <andreyknvl@...il.com>, Peter Zijlstra <peterz@...radead.org>
Subject: Re: [bug] splat at boot

On Thu, Dec 14, 2023 at 5:45 PM Steven Rostedt <rostedt@...dmis.org> wrote:
>
> On Thu, 14 Dec 2023 17:25:46 -0800
> Alexei Starovoitov <alexei.starovoitov@...il.com> wrote:
>
> > Hi All,
> >
> > just noticed a boot splat that probably was there for lone time:
> >
> > [    1.118691] ftrace: allocating 50546 entries in 198 pages
> > [    1.129690] ftrace: allocated 198 pages with 4 groups
> > [    1.130156]
> > [    1.130158] =============================
> > [    1.130159] [ BUG: Invalid wait context ]
> > [    1.130161] 6.7.0-rc3-00837-g403f3e8fda60 #5272 Not tainted
> > [    1.130163] -----------------------------
> > [    1.130165] swapper/0 is trying to lock:
> > [    1.130166] ffff88823fffb1d8 (&zone->lock){....}-{3:3}, at:
> > __rmqueue_pcplist+0xe80/0x1100
> > [    1.130181] other info that might help us debug this:
> > [    1.130182] context-{5:5}
>
> Can you trigger this with CONFIG_PROVE_RAW_LOCK_NESTING disabled?
>
> If not, then I wouldn't worry about it for now, but this will need to be
> addressed when PREEMPT_RT is included.
>
> Basically, a spin_lock() in PREEMPT_RT is converted into a mutex, and most
> interrupt handlers and all softirqs are turned into threads. But there's
> still cases where spin_lock() can not be used. One is for interrupt
> handlers that will not turn into a thread (like the timer interrupt), and
> for when a raw_spin_lock is held. You can't have:
>
>   raw_spin_lock(rawlock);
>   spin_lock(spinlock);
>
> order.

Thanks for explaining.
It's fine without PROVE_RAW_LOCK_NESTING.

Powered by blists - more mailing lists