All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Westphal <fw@strlen.de>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: netfilter-devel@vger.kernel.org
Subject: panic_on_warn and lack of lesser-WARN  (was: Re: [PATCH nf] netfilter: nf_nat: do not reuse an unexpected expectation on RTCP clash)
Date: Sun, 12 Jul 2026 10:40:47 +0200	[thread overview]
Message-ID: <alNTD-kTq6svigxI@strlen.de> (raw)
In-Reply-To: <2026071210-grid-runaround-4318@gregkh>

Greg KH <gregkh@linuxfoundation.org> wrote:
> > > True, but adding new ones is not a good idea, and removing the existing
> > > ones is a good idea.
> > 
> > We're fucked, then.  Can we at least use DEBUG_NET_WARN or something
> > like that so at least fizzers can give us hints about bugs?!
> 
> That's up to you.  If panic_on_warn wasn't an option, about half of the
> kernel CVEs would disappear tomorrow.

That explains your WARN() allergy, I can relate to that.

Its a shame there is nothing like WARN_BENIGN() or similar that doesn't
panic even with panic_on_warn=1.

I get some people really want s/WARN/BUG at run time for things
like "this list is corrupted" or "you tried refcount_inc() on a 0
refcount".  But even for "this refcount is saturated" I don't get
why you want to crash the system right away.

Feels a bit like setting your car on fire because the side window was
slightly dirty :-)

      reply	other threads:[~2026-07-12  8:40 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-10 23:19 netfilter: nf_nat_sip expectation UAF permits local privilege escalation Jaeyeong Lee
2026-07-11  5:29 ` Greg KH
2026-07-11 14:21   ` [PATCH nf] netfilter: nf_nat: do not reuse an unexpected expectation on RTCP clash Jaeyeong Lee
2026-07-11 16:29     ` Florian Westphal
2026-07-12  5:54       ` Greg KH
2026-07-12  7:40         ` Florian Westphal
2026-07-12  7:54           ` Greg KH
2026-07-12  8:08             ` Florian Westphal
2026-07-12  8:20               ` Greg KH
2026-07-12  8:40                 ` Florian Westphal [this message]

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=alNTD-kTq6svigxI@strlen.de \
    --to=fw@strlen.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=netfilter-devel@vger.kernel.org \
    /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.