@@ -29,6 +29,28 @@ a header file, it isn't the full solution. Such interfaces must either
29
29
be fully removed from the kernel, or added to this file to discourage
30
30
others from using them in the future.
31
31
32
+ BUG() and BUG_ON()
33
+ ------------------
34
+ Use WARN() and WARN_ON() instead, and handle the "impossible"
35
+ error condition as gracefully as possible. While the BUG()-family
36
+ of APIs were originally designed to act as an "impossible situation"
37
+ assert and to kill a kernel thread "safely", they turn out to just be
38
+ too risky. (e.g. "In what order do locks need to be released? Have
39
+ various states been restored?") Very commonly, using BUG() will
40
+ destabilize a system or entirely break it, which makes it impossible
41
+ to debug or even get viable crash reports. Linus has `very strong
42
+ <https://lore.kernel.org/lkml/CA+55aFy6jNLsywVYdGp83AMrXBo_P-pkjkphPGrO=82SPKCpLQ@mail.gmail.com/> `_
43
+ feelings `about this
44
+ <https://lore.kernel.org/lkml/CAHk-=whDHsbK3HTOpTF=ue_o04onRwTEaK_ZoJp_fjbqq4+=Jw@mail.gmail.com/> `_.
45
+
46
+ Note that the WARN()-family should only be used for "expected to
47
+ be unreachable" situations. If you want to warn about "reachable
48
+ but undesirable" situations, please use the pr_warn()-family of
49
+ functions. System owners may have set the *panic_on_warn * sysctl,
50
+ to make sure their systems do not continue running in the face of
51
+ "unreachable" conditions. (For example, see commits like `this one
52
+ <https://git.kernel.org/linus/d4689846881d160a4d12a514e991a740bcb5d65a> `_.)
53
+
32
54
open-coded arithmetic in allocator arguments
33
55
--------------------------------------------
34
56
Dynamic size calculations (especially multiplication) should not be
0 commit comments