Re: [RFC][PATCH] make sure that lock_for_kill() callers drop the locks in safe order

Linus Torvalds
2026-04-10T17:31:57Z

On Fri, 10 Apr 2026 at 09:27, Boqun Feng <boqun@kernel.org> wrote:
>
> Notice in rcu_read_unlock_special(), atomicity/preemption count is
> checked in two ways:

Yeah, I didn't go that deep ... That code is inscrutable.

Raising a softirq looks pretty strangein there, since there's
absolutely no reason to believe that the preemption-off region has
ended before the softirq is triggered. It makes sense for the "we're
in hardirq context", but it also does it for that (needs_exp &&
!irqs_were_disabled()) case

So then it depends on the softirq checking it *again*. That all seems
a bit strange.

But it looks like rcu_core_si() does do that, and then falls back to

if (rcu_preempt_need_deferred_qs())
set_need_resched_current();

and it feels like maybe the rcu_read_unlock_special() should just have
done that itself instead of playing softirq games.

Maybe it's some off optimization, but going through the softirq code
doesn't _feel_ like it's the right thing to do.

I don't know this code well enough to judge.

Let's wait to see if Al's patch actually makes any difference. It
*shouldn't* make any difference, and maybe it doesn't. No need to
start chasing RCU bugs that may not even be there.

Jeff?

> @Jeff, just want to confirm, this UAF can be reproduced without
> PREEMPT_RT=y, right?

I haven't seen Jeff's config, but some of the syzbot reports that
*may* be related have configs that look pretty normal and didn't have
PREEMPT_RT.

Linus