Re: [PATCH RFC 5/5] block, nvme: add failed_bio callback for multipath bio failover

[Christoph Hellwig <hch@lst.de>]

Sorry for the late reply, took me a bit to catch up after conference
travel last week and a public holiday on Monday.

On Wed, May 20, 2026 at 09:26:57AM -0600, Keith Busch wrote:
> > Yes, and in the case being addressed here, the "zero capacity" setting
> > is path specific, hence the driver wants to attempt a failover. I
> > imagine general capacity violations are not path specific though, so
> > this is kind of a weird case.
> 
> Oh, and it's not just the zero capacity IO error that multipath wants to
> hanlde. It's also that we've marked the path's disk dead, so there's a
> race if bio_queue_enter() will call bio_io_error() that this patch
> handles. I should have mentioned that case too, which wasn't handled
> with the BIO_REMAPPED flag suggestion.

Well, how do we know the bio actually is owned by the driver?  Callers
both in file systems and remapping block drivers can call bio_io_error
before calling into the driver that owns bi_bdev.

I guess we'd need some flag to desіgnate it is owned by the driver,
and bio_set_dev would have to clear it.

Alternatively we could pas a bdev to bio_submit* and only update
bi_bdev just before the bio is passed to the driver.  Given that
the idea to set the bdev at allocation time didn't work out this
might be sensible, but it will cause a lot of churn.