All of lore.kernel.org
 help / color / mirror / Atom feed
From: Keith Busch <kbusch@kernel.org>
To: Christoph Hellwig <hch@lst.de>
Cc: Keith Busch <kbusch@meta.com>,
	linux-block@vger.kernel.org, linux-nvme@lists.infradead.org,
	axboe@kernel.dk, tom.leiming@gmail.com, coshi036@gmail.com,
	Igor.Achkinazi@dell.com, dlemoal@kernel.org
Subject: Re: [PATCH RFC 5/5] block, nvme: add failed_bio callback for multipath bio failover
Date: Wed, 20 May 2026 09:26:57 -0600	[thread overview]
Message-ID: <ag3Sweie8nWMpmqq@kbusch-mbp> (raw)
In-Reply-To: <ag3ORafKCTyn7TBA@kbusch-mbp>

On Wed, May 20, 2026 at 09:07:49AM -0600, Keith Busch wrote:
> On Wed, May 20, 2026 at 09:27:46AM +0200, Christoph Hellwig wrote:
> > On Tue, May 19, 2026 at 10:23:26AM -0700, Keith Busch wrote:
> > > From: Keith Busch <kbusch@kernel.org>
> > >
> > > The nvme driver has long utilized a zero capacity to indicate the path
> > > isn't reachable, which creates a race condition with IO dispatch when
> > > paths are being detached on a live system: when the block layer rejects
> > > a bio early due to a capacity check failure, drivers with multipath
> > > support using the original bio have no interception point to redirect
> > > the bio to another path.
> >
> > Trying to reverse-engineer - the problem is that the block-layer
> > code catches being beyond the capacity and directly completes the bio,
> > right?
> 
> 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.


  reply	other threads:[~2026-05-20 15:27 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-19 17:23 [PATCH RFC 0/5] block: validate bios against queue limits in the entered context Keith Busch
2026-05-19 17:23 ` [PATCH RFC 1/5] blk-mq: fix status for unaligned bio Keith Busch
2026-05-20  6:56   ` Damien Le Moal
2026-05-20  7:22   ` Christoph Hellwig
2026-05-20 19:54     ` Chao S
2026-05-19 17:23 ` [PATCH RFC 2/5] block: fix invalid zone append status Keith Busch
2026-05-20  6:58   ` Damien Le Moal
2026-05-20  7:23   ` Christoph Hellwig
2026-05-19 17:23 ` [PATCH RFC 3/5] block: validate bio bounds in the queue entered context Keith Busch
2026-05-20  7:22   ` Damien Le Moal
2026-05-20  7:25     ` Damien Le Moal
2026-05-19 17:23 ` [PATCH RFC 4/5] block: move bio validation into __bio_split_to_limits Keith Busch
2026-05-20  7:25   ` Christoph Hellwig
2026-05-20 15:19     ` Keith Busch
2026-05-19 17:23 ` [PATCH RFC 5/5] block, nvme: add failed_bio callback for multipath bio failover Keith Busch
2026-05-20  7:27   ` Christoph Hellwig
2026-05-20 15:07     ` Keith Busch
2026-05-20 15:26       ` Keith Busch [this message]
2026-05-27 14:04         ` Christoph Hellwig

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=ag3Sweie8nWMpmqq@kbusch-mbp \
    --to=kbusch@kernel.org \
    --cc=Igor.Achkinazi@dell.com \
    --cc=axboe@kernel.dk \
    --cc=coshi036@gmail.com \
    --cc=dlemoal@kernel.org \
    --cc=hch@lst.de \
    --cc=kbusch@meta.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=tom.leiming@gmail.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.