Re: [PATCH 2/2] nvme: drop WARN_ON_ONCE on write_stream bounds check

[Greg Kroah-Hartman]

On Thu, Jul 30, 2026 at 03:37:26PM +0200, Christoph Hellwig wrote:
> On Thu, Jul 30, 2026 at 03:18:21PM +0200, Greg Kroah-Hartman wrote:
> > On Thu, Jul 30, 2026 at 01:41:23PM +0200, Christoph Hellwig wrote:
> > > On Tue, Jul 28, 2026 at 08:58:00AM +0200, Greg Kroah-Hartman wrote:
> > > [... monster quote mostly dropped, please stick mail netiquette]
> > > > > but a debug setup you get what you pay for, and I'm really tired of
> > > > > all these totally stupid attempts to make WARN_ON the new BUG_ON.
> > > > > It is not, and that's for a reason.
> > > > 
> > > > I'm tired of it too, but again, if this can be hit by something a user
> > > > does, it ends up being a DoS on the machine :(
> > > 
> > > So let's kill parnic_on_warn?  Or tain the kernel when it is set so
> > > that anyone enaling it knows they have to keep the pieces when it
> > > breaks?
> > 
> > I know why the cloud-boxes want panic-on-warn enabled, as they are
> > cattle and want any potential problem to just reboot the box and keep on
> > going.  And Samsung likes it for their billions of devices for the same
> > reason (it's "safe" to reboot a phone I guess...)
> > 
> > So as much as I would _love_ to drop it, we seem to have real users.
> 
> Then at least add a taint to make it clear to them that they are
> getting themselves into trouble instead of trying taking the only
> useful debug tool away because of bad choices of a few.
> 

syzbot has this same issue, if it ever hits a WARN() output, it stops
and spits out a report.  See the long thread on linux-next about this
right now for a more recent discussion about this.

As for a taint, I'm not sure what you are asking here.  If panic-on-warn
is not enabled, wonderful, a WARN() will spit out a great debugging
message and everyone moves on just fine.

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 :)

thanks,

greg k-h