Re: rt_spin_unlock order of operations [was: Re: [syzbot] [fs?] KASAN: slab-use-after-free Read in shrink_dcache_tree]

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

On Thu, Jun 18, 2026 at 09:59:53PM +0100, Al Viro wrote:

> > https://docs.kernel.org/next/RCU/whatisRCU.html guarantees that
> > spinlock APIs imply RCU, and
> > https://docs.kernel.org/locking/mutex-design.html says: "This is in
> > contrast with spin_unlock() [...], which APIs can be used to guarantee
> > that the memory is not touched by the lock implementation after
> > spin_unlock()/completion_done() releases the lock.".
> > Neither of these explicitly guarantees that the RCU read-side critical
> > section (and the protection against migration?) should still hold
> > while the lock is being dropped, but I think that would fit best with
> > the explicit guarantees?
> 
> I'm trying to recall if PREEMPT_RT had been enabled in the last round of
> UAF in that area back in early April...
> 
> As far as I'm concerned, we *do* need to keep RCU read-side critical area
> all the way until the end of spin_unlock(); it very well might be the
> only thing to prevent freeing the sucker under us.

FWIW, https://lore.kernel.org/all/6a3094e7.428ffe26.258b27.0171.GAE@google.com/
looks potentially related...