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
| ||
|
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