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

[Al Viro <viro@zeniv.linux.org.uk>]

On Fri, Apr 10, 2026 at 09:24:04PM +0100, Al Viro wrote:
> On Fri, Apr 10, 2026 at 12:30:13PM -0700, Linus Torvalds wrote:
> 
> > The reason it exists is because lock_for_kill() can drop d_lock(), but
> > that's in the unlikely case that we cn't just immediately get the
> > inode lock.
> > 
> > So honestly, I think that rcu_read_lock() should be inside
> > lock_for_kill(), rather than in the caller as a "just in case things
> > go down".
> 
> Yup, in the cascade of followups I've mentioned...
> 
> > IOW, that code basically now not only does that typically unnecessary
> > rcu locking (and then unlocking), it does so *because* it knows about
> > the subtle internal behavior of lock_for_kill().
> > 
> > In contrast, if we put it inside lock_for_kill(), all we need is a
> > fairly straightforward comment along the lines of
> > 
> >   "we're dropping the spinlock in order to take the inode lock, but
> > the caller may be depending on RCU behavior so we need to take the rcu
> > read lock first".
> > 
> >  that would turn strange illogical code that also generates worse code
> > into straightforwardly explained code that also performs better.
> > 
> > Ok, so "performs better" is kind of exaggerated, in that obviously the
> > extra rcu_read_lock/unlock sequences aren't exactly expensive, but
> > still - I feel it's a win-win to just do this differently.
> > 
> > Or am I missing somethign else?
> 
> Mostly that fast_dput() calling conventions would need to change a bit
> as well.
> 
> With the above as step 1,
[snip]

FWIW, I would really like to figure out what the hell is going on with
those UAF; livelock elimination (which is clearly needed as well -
there's an easy way to turn that livelock into hard lock reliably eating
a CPU on an SMP box) is likely to hide whatever the bug is.  And it
does look like RCU bugs are not the cause of what Jeff is occasionally
seeing - not with their config.  So there's something else going on ;-/
Jeff's reports are 6.11--6.13; Helge's parisc ones are 6.16--6.19.
If they are using the stock debian parisc kernel, it's PREEMPT_NONE
config (AFAICS) and in that case RCU is not the cause there as well...

Back to trying to put together a proof of correctness and see where
it breaks ;-/  If nothing else, that should give a set of assertion
checks to try and slap on top of the kernels involved...