Re: [PATCH 17/32] fs: Move metadata bhs tracking to a separate struct

Jan Kara <[email protected]> Thu, 5 Mar 2026 17:39:59 +0100
Newsgroups gmane.linux.kernel.aio.general,gmane.linux.file-systems,gmane.comp.file-systems.ext4,gmane.linux.kernel.mm
Message-ID <5quave3vkmvgstqggaijh3b5225kfofkri6psl5xsib27gknq2@lzaj6uzs2pqj>
On Wed 04-03-26 05:40:33, Christoph Hellwig wrote:
> On Tue, Mar 03, 2026 at 11:34:06AM +0100, Jan Kara wrote:
> > +static void remove_assoc_queue(struct buffer_head *bh)
> > +{
> > +	struct address_space *mapping;
> > +	struct mapping_metadata_bhs *mmb;
> > +
> > +	/*
> > +	 * The locking dance is ugly here. We need to acquire lock
> > +	 * protecting metadata bh list while possibly racing with bh
> > +	 * being removed from the list or moved to a different one.  We
> > +	 * use RCU to pin mapping_metadata_bhs in memory to
> > +	 * opportunistically acquire the lock and then recheck the bh
> > +	 * didn't move under us.
> > +	 */
> 
> Should the buffer_head simply have a pointer to the metadata bh list,
> as that would avoid all this and keep a lot of the references to the
> list self-contained?

Yes, after some thinking that should be doable if we then add pointer to
address_space to struct mapping_metadata_bhs. I'll try how the patches are
going to look like.

								Honza
-- 
Jan Kara <[email protected]>
SUSE Labs, CR

--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to [email protected].  For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"[email protected]">[email protected]</a>