From: Christoph Hellwig <hch@lst.de>
To: Keith Busch <kbusch@meta.com>
Cc: linux-block@vger.kernel.org, linux-nvme@lists.infradead.org,
axboe@kernel.dk, hch@lst.de, tom.leiming@gmail.com,
coshi036@gmail.com, Igor.Achkinazi@dell.com, dlemoal@kernel.org,
Keith Busch <kbusch@kernel.org>
Subject: Re: [PATCH RFC 5/5] block, nvme: add failed_bio callback for multipath bio failover
Date: Wed, 20 May 2026 09:27:46 +0200 [thread overview]
Message-ID: <20260520072746.GD14937@lst.de> (raw)
In-Reply-To: <20260519172326.3462354-6-kbusch@meta.com>
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?
IMHO the right fix is to get rid of the capacity hacks, and have a flag
we can catch in the nvme driver and complete through the mechanisms.
Having a callback into the driver for a specific error codition seems
odd. And I think there's a bunch of cases where we could call this on
a bio the driver hasn't even seen yet, including from file system code.
next prev parent reply other threads:[~2026-05-20 7: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 [this message]
2026-05-20 15:07 ` Keith Busch
2026-05-20 15:26 ` Keith Busch
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=20260520072746.GD14937@lst.de \
--to=hch@lst.de \
--cc=Igor.Achkinazi@dell.com \
--cc=axboe@kernel.dk \
--cc=coshi036@gmail.com \
--cc=dlemoal@kernel.org \
--cc=kbusch@kernel.org \
--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.