From: David Hildenbrand <david@redhat.com>
To: Akira Yokosawa <akiyks@gmail.com>
Cc: linuxppc-dev@lists.ozlabs.org, bhe@redhat.com, corbet@lwn.net,
dwaipayanray1@gmail.com, linux-doc@vger.kernel.org,
npiggin@gmail.com, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, joe@perches.com,
torvalds@linux-foundation.org, David.Laight@ACULAB.COM,
jani.nikula@linux.intel.com, apw@canonical.com,
lukas.bulwahn@gmail.com, akpm@linux-foundation.org,
dyoung@redhat.com, mingo@kernel.org, vgoyal@redhat.com
Subject: Re: [PATCH v1 1/3] coding-style.rst: document BUG() and WARN() rules ("do not crash the kernel")
Date: Thu, 22 Sep 2022 16:41:49 +0200 [thread overview]
Message-ID: <9fc9759d-ac74-ca8f-874c-5058758c3ea1@redhat.com> (raw)
In-Reply-To: <93343c05-f31e-cfbe-6650-8ea8d79e6d55@gmail.com>
>>
>> +22) Do not crash the kernel
>> +---------------------------
>> +
>> +In general, it is not the kernel developer's decision to crash the kernel.
>> +
>> +Avoid panic()
>> +=============
> This looks to me like a subsection-level title. The adornment symbol
> needs to be:
>
> *************
>
>> +
>> +panic() should be used with care and primarily only during system boot.
>> +panic() is, for example, acceptable when running out of memory during boot and
>> +not being able to continue.
>> +
>> +Use WARN() rather than BUG()
>> +============================
> Ditto.
>
>> +
>> +Do not add new code that uses any of the BUG() variants, such as BUG(),
>> +BUG_ON(), or VM_BUG_ON(). Instead, use a WARN*() variant, preferably
>> +WARN_ON_ONCE(), and possibly with recovery code. Recovery code is not
>> +required if there is no reasonable way to at least partially recover.
>> +
>> +"I'm too lazy to do error handling" is not an excuse for using BUG(). Major
>> +internal corruptions with no way of continuing may still use BUG(), but need
>> +good justification.
>> +
>> +Use WARN_ON_ONCE() rather than WARN() or WARN_ON()
>> +**************************************************
> These wrong adornment symbol confuse ReST parser of Sphinx and results in
> the build error from "make htmldocs" at this title (long message folded):
Thanks,
the following on top should do the trick:
diff --git a/Documentation/process/coding-style.rst b/Documentation/process/coding-style.rst
index e05899cbfd49..9efde65ac2f3 100644
--- a/Documentation/process/coding-style.rst
+++ b/Documentation/process/coding-style.rst
@@ -1192,14 +1192,14 @@ expression used. For instance:
In general, it is not the kernel developer's decision to crash the kernel.
Avoid panic()
-=============
+*************
panic() should be used with care and primarily only during system boot.
panic() is, for example, acceptable when running out of memory during boot and
not being able to continue.
Use WARN() rather than BUG()
-============================
+****************************
Do not add new code that uses any of the BUG() variants, such as BUG(),
BUG_ON(), or VM_BUG_ON(). Instead, use a WARN*() variant, preferably
--
Thanks,
David / dhildenb
next prev parent reply other threads:[~2022-09-22 14:42 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-20 12:22 [PATCH v1 0/3] coding-style.rst: document BUG() and WARN() rules David Hildenbrand
2022-09-20 12:23 ` [PATCH v1 1/3] coding-style.rst: document BUG() and WARN() rules ("do not crash the kernel") David Hildenbrand
2022-09-21 4:40 ` Kalle Valo
2022-09-22 14:12 ` David Hildenbrand
2022-09-26 7:44 ` Kalle Valo
2022-10-04 12:32 ` David Hildenbrand
2022-09-22 13:43 ` Akira Yokosawa
2022-09-22 14:41 ` David Hildenbrand [this message]
2022-09-23 2:26 ` John Hubbard
2022-09-23 2:37 ` John Hubbard
2022-09-23 10:55 ` David Hildenbrand
2022-09-20 12:23 ` [PATCH v1 2/3] powerpc/prom_init: drop PROM_BUG() David Hildenbrand
2022-09-21 13:02 ` Michael Ellerman
2022-09-21 13:03 ` David Hildenbrand
2022-09-20 12:23 ` [PATCH v1 3/3] checkpatch: warn on usage of VM_BUG_ON() and other BUG variants David Hildenbrand
2022-09-23 2:05 ` John Hubbard
2022-09-23 2:11 ` Joe Perches
2022-09-23 2:20 ` John Hubbard
2022-09-23 10:58 ` David Hildenbrand
2022-10-04 13:24 ` (subset) [PATCH v1 0/3] coding-style.rst: document BUG() and WARN() rules Michael Ellerman
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=9fc9759d-ac74-ca8f-874c-5058758c3ea1@redhat.com \
--to=david@redhat.com \
--cc=David.Laight@ACULAB.COM \
--cc=akiyks@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=apw@canonical.com \
--cc=bhe@redhat.com \
--cc=corbet@lwn.net \
--cc=dwaipayanray1@gmail.com \
--cc=dyoung@redhat.com \
--cc=jani.nikula@linux.intel.com \
--cc=joe@perches.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=lukas.bulwahn@gmail.com \
--cc=mingo@kernel.org \
--cc=npiggin@gmail.com \
--cc=torvalds@linux-foundation.org \
--cc=vgoyal@redhat.com \
/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 NNTP newsgroup(s).