Re: [PATCH] xfs: fix a buffer lookup against removal race

[Christoph Hellwig <hch@lst.de>]

On Sat, May 16, 2026 at 07:59:17AM +1000, Dave Chinner wrote:
> > +	if (bp) {
> > +		/*
> > +		 * If there is an existing buffer with a dead lockref, retry
> > +		 * until the new buffer is added or usable buffer is found.
> > +		 */
> > +		if (!lockref_get_not_dead(&bp->b_lockref)) {
> > +			rcu_read_unlock();
> > +			goto retry;
> > +		}
> 
> Like the inode cache, there probably should be a delay here rather
> than spinning hard. There is no guarantee that the object actually
> appears removed from the cache until the RCU grace period expires,
> though typically races that find objects being removed are much
> shorter duration than that.

I don't think in the current version we need it because it is
basically imposisble to hit.  But with your comment below fixed
we do need it, so I'll add it.

> Also, is it safe to run lockref_get_not_dead() whilst some other
> thread is racing to get lockref.lock and calls lockref_mark_dead()
> on it? 

Yes, it is specifically designed for that: the lockref idea is that you
can do fast path increment/decrements using atomics that are serialized
as if you'd always take the lock around manual opeations on the count
field.  The ability to mark it dead under the lock and synchronize
against atomic increments one of the most important aspects of that.

> That'll cause issues. RCU algorithms require the object to be marked
> dead before it is removed from the index so that RCU lookup races
> that find it after removal (i.e.  during the RCU grace period) see
> the object as dead, not as a valid buffer (think RT preemption
> between remove and mark dead).

Yes, this should be switched around.  And with that the retry loop
above becomes more likely and needs the cpu_relax().

I wrote a version doing this and ran it through test over the weekend,
which I'll post soon.