From: David Hildenbrand <david@redhat.com>
To: Alex Elder <elder@linaro.org>, corbet@lwn.net
Cc: gregkh@linuxfoundation.org, workflows@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Documentation: coding-style: don't encourage WARN*()
Date: Fri, 19 Apr 2024 09:16:41 +0200 [thread overview]
Message-ID: <10af93f8-83f2-48ce-9bc3-80fe4c60082c@redhat.com> (raw)
In-Reply-To: <20240414170850.148122-1-elder@linaro.org>
On 14.04.24 19:08, Alex Elder wrote:
> Several times recently Greg KH has admonished that variants of WARN()
> should not be used, because when the panic_on_warn kernel option is set,
> their use can lead to a panic. His reasoning was that the majority of
> Linux instances (including Android and cloud systems) run with this option
> enabled. And therefore a condition leading to a warning will frequently
> cause an undesirable panic.
>
> The "coding-style.rst" document says not to worry about this kernel
> option. Update it to provide a more nuanced explanation.
>
> Signed-off-by: Alex Elder <elder@linaro.org>
> ---
> Documentation/process/coding-style.rst | 21 +++++++++++----------
> 1 file changed, 11 insertions(+), 10 deletions(-)
>
> diff --git a/Documentation/process/coding-style.rst b/Documentation/process/coding-style.rst
> index 9c7cf73473943..bce43b01721cb 100644
> --- a/Documentation/process/coding-style.rst
> +++ b/Documentation/process/coding-style.rst
> @@ -1235,17 +1235,18 @@ example. Again: WARN*() must not be used for a condition that is expected
> to trigger easily, for example, by user space actions. pr_warn_once() is a
> possible alternative, if you need to notify the user of a problem.
>
> -Do not worry about panic_on_warn users
> -**************************************
> +The panic_on_warn kernel option
> +********************************
>
> -A few more words about panic_on_warn: Remember that ``panic_on_warn`` is an
> -available kernel option, and that many users set this option. This is why
> -there is a "Do not WARN lightly" writeup, above. However, the existence of
> -panic_on_warn users is not a valid reason to avoid the judicious use
> -WARN*(). That is because, whoever enables panic_on_warn has explicitly
> -asked the kernel to crash if a WARN*() fires, and such users must be
> -prepared to deal with the consequences of a system that is somewhat more
> -likely to crash.
> +Note that ``panic_on_warn`` is an available kernel option. If it is enabled,
> +a WARN*() call whose condition holds leads to a kernel panic. Many users
> +(including Android and many cloud providers) set this option, and this is
> +why there is a "Do not WARN lightly" writeup, above.
> +
> +The existence of this option is not a valid reason to avoid the judicious
> +use of warnings. There are other options: ``dev_warn*()`` and ``pr_warn*()``
> +issue warnings but do **not** cause the kernel to crash. Use these if you
> +want to prevent such panics.
>
> Use BUILD_BUG_ON() for compile-time assertions
> **********************************************
Did you even read the history about that? Likely not, otherwise I wouldn't
have to learn about this patch on lwn.net.
I suggest reading:
commit 1cfd9d7e43d5a1cf739d1420b10b1e65feb02f88
Author: David Hildenbrand <david@redhat.com>
Date: Fri Sep 23 13:34:24 2022 +0200
coding-style.rst: document BUG() and WARN() rules ("do not crash the kernel")
which includes links to relevant discussions between me and Linus. Most
relevant to the discussion is [1].
All that's written in the document right now (use WARN_ON_ONCE() *lightly*) is precisely
what I still think we should do. That's the case *1.5 years* after I documented that.
Clear NACK from my side: "If you set 'panic_on_warn' you get to keep both
pieces when something breaks." [1]
[1] https://lore.kernel.org/all/CAHk-=wgF7K2gSSpy=m_=K3Nov4zaceUX9puQf1TjkTJLA2XC_g@mail.gmail.com/
--
Cheers,
David / dhildenb
prev parent reply other threads:[~2024-04-19 7:16 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-14 17:08 [PATCH] Documentation: coding-style: don't encourage WARN*() Alex Elder
2024-04-14 19:48 ` Laurent Pinchart
2024-04-14 20:06 ` Alex Elder
2024-04-15 5:21 ` Greg KH
2024-04-15 8:25 ` Laurent Pinchart
2024-04-15 8:33 ` Greg KH
2024-04-15 8:42 ` Laurent Pinchart
2024-04-15 5:22 ` Greg KH
2024-04-15 8:07 ` Christoph Hellwig
2024-04-15 8:35 ` Greg KH
2024-04-15 8:46 ` Christoph Hellwig
2024-04-15 16:26 ` Kees Cook
2024-04-18 15:57 ` Jason Gunthorpe
2024-04-18 16:14 ` Eric Biggers
2024-04-18 17:12 ` Kees Cook
2024-04-18 22:33 ` John Hubbard
2024-04-19 7:16 ` David Hildenbrand [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=10af93f8-83f2-48ce-9bc3-80fe4c60082c@redhat.com \
--to=david@redhat.com \
--cc=corbet@lwn.net \
--cc=elder@linaro.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=workflows@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).