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

[Jeff Layton <jlayton@kernel.org>]

On Fri, 2026-04-10 at 10:31 -0700, Linus Torvalds wrote:
> 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.
> 
> 

I've not been able to reproduce the UAF at all.

It was possible to reproduce the hang that we were seeing by injecting
an mdelay() just after the cond_resched() in __dentry_kill(), but Al's
other series seems to have fixed that.

The UAF seems to be dependent on those hangs somehow, but we were never
able to get one to fire from a reproducer attempt. They just
occasionally pop up when these stalls occur.
-- 
Jeff Layton <jlayton@kernel.org>