Re: [PATCH 02/12] xfs: consolidate buffer locking in xfs_buf_get_map

On Mon, Jul 20, 2026 at 09:59:02AM +0200, Christoph Hellwig wrote:
> On Fri, Jul 17, 2026 at 10:13:10AM -0400, Brian Foster wrote:
> > I see that you're intentionally separating out the lookup from the buf
> > data locking, but it does still look like we're making a potential
> > functional tradeoff here by changing the insertion side locking.
> 
> Yes.  That commit log tries to cover that.
> 
> > Note
> > that I don't object or know that it matters in any way, I'd just suggest
> > to add a note about this in the commit log in case somebody has to refer
> > back to this in the future.
> 
> ... but I guess the wording wasn't goot enough.  I'll try to improve it.

It could emphasize that b_lockref is used to make rcu lookups safe
against a freed buffer whereas b_sema is used to prevent racing threads
from doing anything non-trivial with the buffer once they've gotten
themselves a lockref, and that's why the comment is obsolete and can go
away.

Or modify the comment?

	/*
	 * The creator of a new buffer holds a lockref to that buffer.
	 * This ensures that the buffer is owned by the caller and
	 * racing RCU lookups right after inserting into the hash table
	 * are safe against freeing.
	 *
	 * Racing threads trying to look up the buffer will have to wait
	 * for b_sema to do anything non-trivial.  Note that b_sema is
	 * not locked at creation time.
	 */

Is there a subtlety here that the buffer creator might not be the one to
read the buffer contents in from disk if another thread happens to find
the buffer in the cache, take b_sema, notice that it's not XBF_DONE, and
start the read on its own?

--D