Received-SPF: pass (google.com: domain of linux-kernel+bounces-331-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Precedence: bulk
MIME-Version: 1.0
References: <CAADnVQ+dPML0DW=Miuq=n7nC8m4gcPj7Dk_nhedzs9zTE30arw@mail.gmail.com>
 <20231214204629.1b380b82@gandalf.local.home>
In-Reply-To: <20231214204629.1b380b82@gandalf.local.home>
From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Date: Thu, 14 Dec 2023 17:59:36 -0800
Message-ID: <CAADnVQJSvFeqRT+x3y5AWOC396nOdZQ4Zf66Es-71PxBtpj_GA@mail.gmail.com>
Subject: Re: [bug] splat at boot
To: Steven Rostedt <rostedt@goodmis.org>
Cc: bpf <bpf@vger.kernel.org>, Network Development <netdev@vger.kernel.org>, 
	LKML <linux-kernel@vger.kernel.org>, "Paul E. McKenney" <paulmck@kernel.org>, 
	Stephen Rothwell <sfr@canb.auug.org.au>, Alexander Potapenko <glider@google.com>, 
	Andrey Konovalov <andreyknvl@gmail.com>, Peter Zijlstra <peterz@infradead.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Dec 14, 2023 at 5:45=E2=80=AFPM Steven Rostedt <rostedt@goodmis.org=
> wrote:
>
> On Thu, 14 Dec 2023 17:25:46 -0800
> Alexei Starovoitov <alexei.starovoitov@gmail.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] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > [    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 mos=
t
> 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.