[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250303115522.437773d7@gandalf.local.home>
Date: Mon, 3 Mar 2025 11:55:22 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Strforexc yn <strforexc@...il.com>
Cc: Lai Jiangshan <jiangshanlai@...il.com>, "Paul E. McKenney"
<paulmck@...nel.org>, Josh Triplett <josh@...htriplett.org>, Mathieu
Desnoyers <mathieu.desnoyers@...icios.com>, rcu@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: KASAN: global-out-of-bounds Read in srcu_gp_start_if_needed
On Mon, 3 Mar 2025 11:47:11 -0500
Steven Rostedt <rostedt@...dmis.org> wrote:
> > [ 92.322619][ T28] ? srcu_gp_start_if_needed+0x1a9/0x5f0
> > [ 92.322636][ T28] srcu_gp_start_if_needed+0x1a9/0x5f0
>
> The lock taken is from the passed in rcu_pending pointer.
>
> > [ 92.322655][ T28] rcu_pending_enqueue+0x686/0xd30
I figured out what likely triggered the lockdep warning too. I thought
rcu_pending_equeue() was an internal RCU function, but then when I looked
at what directory it was in (found it in emacs so I only saw the file name
and not the path), I see that function is internal to bcachefs.
That function also has:
local_irq_save(flags);
p = this_cpu_ptr(pending->p);
spin_lock(&p->lock);
That is a sure sign of an RT disaster waiting to happen. As in PREEMPT_RT
that spin_lock turns into a mutex, and just before, you disable interrupts.
And yes, lockdep will report that as a bug.
-- Steve
Powered by blists - more mailing lists