All of lore.kernel.org
 help / color / mirror / Atom feed
From: Teng Liu <27rabbitlt@gmail.com>
To: Qu Wenruo <wqu@suse.com>
Cc: linux-btrfs@vger.kernel.org, dsterba@suse.com, clm@fb.com,
	 linux-kernel@vger.kernel.org
Subject: Re: [PATCH] btrfs: wait for in-flight readahead BIOs on open_ctree() error
Date: Mon, 30 Mar 2026 20:00:12 +0200	[thread overview]
Message-ID: <acq5Y9VuDI9htA-I@rabbitArch> (raw)
In-Reply-To: <840361b6-9b27-4419-b8ab-891ab254fac9@suse.com>

On 2026-03-30 08:51, Qu Wenruo wrote:
> 
> 
> 在 2026/3/30 08:36, Qu Wenruo 写道:
> > 
> > 
> > Even you wait for all bios, it can still cause problems.
> > 
> > As the bio counter is only for btrfs bio layer, we still have
> > btrfs_bio::end_io called after btrfs_bio_counter_dec().
> > 
> > And if the full fs_info has been freed, then at end_bbio_meta_read(), we
> > can still have problems as btrfs_validate_extent_buffer() will access eb
> > (bbio->private) and fs_info (eb->fs_info), which triggers use after
> > free.
> > 
> > So using that bio counter is not going to solve all problems, but only
> > reducing the race window thus masking the problem.
> > 
> > 
> > The following ideas come up to me, but neither seems as simple as your
> > current one:
> > 
> > 1) Introduce a dedicated counter for metadata readahead/reads
> >     This seems to be the simplest one among all.
> >     But the only usage is only the error handling, thus may not be
> >     worthy.
> > 
> > 2) Disable metadata readahead during open_ctree()
> >     Which will delay the mount, especially for large extent tree without
> >     bgt feature.
> > 
> > 3) Use buffer_tree xarray to iterate through all ebs
> >     Since this is only for error handling of open_ctree(), we're fine to
> >     do the full xarray iteration, and wait for any eb that has
> >     EXTENT_BUFFER_READING flag.
> > 
> >     The problem is, we do not have a dedicated tag like
> >     PAGECACHE_TAG_(TOWRITE|DIRTY) to easily catch all dirty/writeback
> >     ebs.
> >     So the only option is to go through each eb and check their flags.
> > 
> >     I think this is the one with minimal impact, but may cause much
> >     longer runtime during this error handling path.
> > 
> > My personal preference is option 3).
> 
> Or the 4th one, which is only an idea and I haven't yet verified:
> 
> 4) Handle error from invalidate_inode_pages2()
>    Currently we just call invalidate_inode_pages2() on btree inode and
>    expect it to return 0.
> 
>    But if there is still an eb reading pending, it will make that
>    function to return -EBUSY, as try_release_extent_buffer() will
>    find a eb whose refs is not 0, and refuse the release that eb which
>    belongs to a folio.
> 
>    That should be a good indicator of any pending metadata reads.
> 
>    So if that invalidate_inode_pages2() returned -EBUSY, we should wait
>    retry until it returns 0.
> 
> 

Thanks! Yes, it makes sense, simply waiting on the bio counter doesnt
fix the problem here. 

Among the options, I prefer option 3. Although it may be slower, but it
only happens in mount failure path so extra cost seems acceptable.

I am quite new to btrfs codebase so I dont know whether
`invalidate_inode_pages2()` would be a reliable solution so maybe I
should start with option 3?



  reply	other threads:[~2026-03-30 18:00 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-29  6:31 [PATCH] btrfs: wait for in-flight readahead BIOs on open_ctree() error Teng Liu
2026-03-29  7:03 ` Qu Wenruo
2026-03-29 17:23   ` Teng Liu
2026-03-29 22:06     ` Qu Wenruo
2026-03-29 22:21       ` Qu Wenruo
2026-03-30 18:00         ` Teng Liu [this message]
2026-03-30 21:48           ` Qu Wenruo
2026-03-30 22:14             ` Qu Wenruo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=acq5Y9VuDI9htA-I@rabbitArch \
    --to=27rabbitlt@gmail.com \
    --cc=clm@fb.com \
    --cc=dsterba@suse.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=wqu@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.