From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Keith Busch <kbusch@kernel.org>
Cc: Christoph Hellwig <hch@lst.de>,
Hari Mishal <harimishal1@gmail.com>, Jens Axboe <axboe@kernel.dk>,
Sagi Grimberg <sagi@grimberg.me>, Hannes Reinecke <hare@suse.de>,
Kanchan Joshi <joshi.k@samsung.com>,
Nitesh Shetty <nj.shetty@samsung.com>,
linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] nvme: drop WARN_ON_ONCE on write_stream bounds check
Date: Thu, 30 Jul 2026 17:02:32 +0200 [thread overview]
Message-ID: <2026073054-visiting-plural-7eb0@gregkh> (raw)
In-Reply-To: <amtfOzqITuEbYL3g@kbusch-mbp>
On Thu, Jul 30, 2026 at 08:27:07AM -0600, Keith Busch wrote:
> On Thu, Jul 30, 2026 at 04:04:03PM +0200, Greg Kroah-Hartman wrote:
> > It's only the systems that have panic-on-warn enabled that need to worry
> > about user-triggered calls to that macro, and those systems know what
> > they are getting themselves into, including the huge number of CVE fixes
> > they then need to be responsible for backporting :)
>
> This is a bit of a rug pull. We've long held the pattern that WARN is an
> appropriate macro for conditions that should never happen, but don't
> leave the system in an unrecoverable or compromised state. For
> unrecoverable conditions, use BUG. It has been a valuable tool for
> debugging and bug reporting.
Sure, that's fine, just don't have such a path that a user can trigger,
and all is good. syzbot has been dealing with this for years, it's not
a rug-pull at all.
thanks,
greg k-h
next prev parent reply other threads:[~2026-07-30 16:21 UTC|newest]
Thread overview: 22+ 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-29 11:47 ` Hari Mishal
2026-07-30 5:11 ` Kanchan Joshi
2026-07-25 13:51 ` [PATCH 2/2] nvme: drop WARN_ON_ONCE on write_stream bounds check Hari Mishal
2026-07-27 14:24 ` Keith Busch
2026-07-27 19:19 ` Greg Kroah-Hartman
2026-07-27 22:51 ` Keith Busch
2026-07-28 5:15 ` Greg Kroah-Hartman
2026-07-28 5:18 ` Christoph Hellwig
2026-07-28 6:58 ` Greg Kroah-Hartman
2026-07-28 9:46 ` Keith Busch
2026-07-28 10:34 ` Greg Kroah-Hartman
2026-07-30 11:41 ` Christoph Hellwig
2026-07-30 13:18 ` Greg Kroah-Hartman
2026-07-30 13:37 ` Christoph Hellwig
2026-07-30 14:04 ` Greg Kroah-Hartman
2026-07-30 14:27 ` Keith Busch
2026-07-30 15:02 ` Greg Kroah-Hartman [this message]
2026-07-30 19:33 ` 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=2026073054-visiting-plural-7eb0@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=axboe@kernel.dk \
--cc=hare@suse.de \
--cc=harimishal1@gmail.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox