From: Hari Mishal <harimishal1@gmail.com>
To: Keith Busch <kbusch@kernel.org>, Jens Axboe <axboe@kernel.dk>,
Christoph Hellwig <hch@lst.de>, Sagi Grimberg <sagi@grimberg.me>
Cc: Hannes Reinecke <hare@suse.de>,
Kanchan Joshi <joshi.k@samsung.com>,
Nitesh Shetty <nj.shetty@samsung.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org,
Hari Mishal <harimishal1@gmail.com>
Subject: [PATCH 2/2] nvme: drop WARN_ON_ONCE on write_stream bounds check
Date: Sat, 25 Jul 2026 15:51:11 +0200 [thread overview]
Message-ID: <20260725135111.14041-3-harimishal1@gmail.com> (raw)
In-Reply-To: <20260725135111.14041-1-harimishal1@gmail.com>
write_stream is validated against bdev_max_write_streams() in both
generic block direct I/O (block/fops.c) and F2FS before a bio
carrying it is ever built, so write_stream > nr_plids shouldn't be
reachable through any current legitimate path. The remaining users
of bio->bi_write_stream elsewhere in the block layer only copy an
already-validated value between bios (bio.c, blk-crypto-fallback.c)
or compare it for merge eligibility (blk-merge.c); none of them
introduce a new, unvalidated value.
Using WARN_ON_ONCE as the backstop for that assumption isn't worth
it given how many deployed systems run with panic-on-warn enabled;
the existing graceful return BLK_STS_INVAL already handles it on
its own.
Signed-off-by: Hari Mishal <harimishal1@gmail.com>
---
drivers/nvme/host/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index bdc5f07f5bf0..48ae0ffbbe6e 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -1023,7 +1023,7 @@ static inline blk_status_t nvme_setup_rw(struct nvme_ns *ns,
u16 write_stream = req->bio->bi_write_stream;
if (ns->head->nr_plids) {
- if (WARN_ON_ONCE(write_stream > ns->head->nr_plids))
+ if (write_stream > ns->head->nr_plids)
return BLK_STS_INVAL;
if (write_stream) {
--
2.43.0
next prev parent reply other threads:[~2026-07-25 13:51 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-25 13:51 [PATCH 0/2] nvme: fix racy access to FDP placement ID array Hari Mishal
2026-07-25 13:51 ` [PATCH 1/2] " Hari Mishal
2026-07-27 13:31 ` Kanchan Joshi
2026-07-27 14:22 ` Kanchan Joshi
2026-07-25 13:51 ` Hari Mishal [this message]
2026-07-27 14:24 ` [PATCH 2/2] nvme: drop WARN_ON_ONCE on write_stream bounds check Keith Busch
2026-07-27 19:19 ` Greg Kroah-Hartman
2026-07-27 22:51 ` Keith Busch
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=20260725135111.14041-3-harimishal1@gmail.com \
--to=harimishal1@gmail.com \
--cc=axboe@kernel.dk \
--cc=gregkh@linuxfoundation.org \
--cc=hare@suse.de \
--cc=hch@lst.de \
--cc=joshi.k@samsung.com \
--cc=kbusch@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=nj.shetty@samsung.com \
--cc=sagi@grimberg.me \
/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.