Re: [PATCH 2/2] block: don't set BIO_QUIET for BLK_STS_AGAIN

[Christoph Hellwig <hch@lst.de>]

On Mon, May 18, 2026 at 02:34:49PM +0200, Jan Kara wrote:
> > Commit abb30460bda2 ("block: mark bio_wouldblock_error() bio with
> > BIO_QUIET") added this to suppress buffer_head warnings, but neither
> > when this commit was added nor now any buffer_head using code actually
> > ever sets REQ_NOWAIT which can lead to BLK_STS_AGAIN.
> > 
> > Remove the special handling for now.  If we ever plan to use REQ_NOWAIT
> > for buffer_head based I/O we're better off handling BLK_STS_AGAIN in
> > the completion handler as it actually needs to retry the I/O as well.
> > 
> > Signed-off-by: Christoph Hellwig <hch@lst.de>
> 
> So I agree about the bh argument but bio_wouldblock_error() is not specific
> to bh path in any way, is it? So do we expect all bi_end_io handlers to
> check for BLK_STS_AGAIN and avoid complaining to logs in case of that? Not
> that all of them would be currently checking for BIO_QUIET either so I'm
> mostly trying to figure out what's the expected handling.

File system would need special handling for BLK_STS_AGAIN were we to wire
it up again (in upstream we have the dead direct-io code removed in
patch 1, and an incorrect use in iomap polled I/O I sent a separate patch
for), because simply bubbling it up as -EAGAIN will generally do the
wrong thing.  We ran into file system corruption last time we did it due
to non-idempotency of writes and general locking issues with just
retrying at a higher level.

Thus the rough consensus was that If we want to support fs-issued
REQ_NOWAIT I/O we'd first need to add infrastructure to retry them from
a blocking context at the bio-level, preferably in the block layer
itself.