linux-kernel - Re: [PATCH] debug: Deprecate BUG_ON() use in new code, introduce CRASH

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 08 Jun 2015 09:40:22 +0200
From:	Alexander Holler <holler@...oftware.de>
To:	Ingo Molnar <mingo@...nel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	Tejun Heo <htejun@...il.com>,
	Louis Langholtz <lou_langholtz@...com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	trivial@...nel.org, Rusty Russell <rusty@...tcorp.com.au>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH] debug: Deprecate BUG_ON() use in new code, introduce
 CRASH_ON()

Am 08.06.2015 um 09:12 schrieb Ingo Molnar:
>
> * Linus Torvalds <torvalds@...ux-foundation.org> wrote:
>
>> Stop with the random BUG_ON() additions.
>
> Yeah, so I propose the attached patch which attempts to resist new BUG_ON()
> additions.

As this reminded me at flame I received once from a maintainer because I 
wanted to avoid a desastrous memory corruption by using a BUG_ON(). 
maybe someone should mention that a BUG_ON or now CRASH_ON should be 
still prefered instead of some random memory corruption which might lead 
to worse things. Or how is the viewpoint of the kernel masters in regard 
to memory corruptions and use of BUG_ON, WARN_ON or CRASH_ON?

Regards,

Alexander Holler

>
> Thanks,
>
> 	Ingo
>
> ================================>
>  From 724052923fbae2e3a14e0b9383c89b18217d817f Mon Sep 17 00:00:00 2001
> From: Ingo Molnar <mingo@...nel.org>
> Date: Mon, 8 Jun 2015 09:01:43 +0200
> Subject: [PATCH] debug: Deprecate BUG_ON() use in new code, introduce CRASH_ON()
>
> So people still keep adding random BUG_ON() lines, as a mistaken practice
> to put asserts that will never trigger, into supposedly perfect kernel code.
>
> So such BUG_ON()s should either not be added, because the code is truly
> perfect, or if there's a chance that it's imperfect, use WARN_ON() instead
> and limp along, in the hope of getting some debug information back from
> the user.
>
> Using BUG_ON() will just hang or reboot most systems, with no useful
> feedback provided. It's as user hostile as it gets.
>
> Add a checkpatch rule that warns against new BUG_ON() uses:
>
>    WARNING: Using BUG_ON() is generally wrong, use WARN_ON() instead - or CRASH_ON() if the kernel absolutely must crash.
>
> CRASH_ON() can be used in code that must absolutely crash right then,
> in the very rare case where there's no way the system can be allowed
> to continue execution.
>
> It should be used sparingly, and its name will hopefully achieve this.
>
> Signed-off-by: Ingo Molnar <mingo@...nel.org>
> ---
>   include/asm-generic/bug.h | 7 +++++++
>   scripts/checkpatch.pl     | 6 ++++++
>   2 files changed, 13 insertions(+)
>
> diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
> index 630dd2372238..c6424723277b 100644
> --- a/include/asm-generic/bug.h
> +++ b/include/asm-generic/bug.h
> @@ -165,6 +165,13 @@ extern void warn_slowpath_null(const char *file, const int line);
>   #define WARN_TAINT(condition, taint, format...) WARN(condition, format)
>   #define WARN_TAINT_ONCE(condition, taint, format...) WARN(condition, format)
>
> +/*
> + * BUG_ON() is deprecated, use either one of the WARN_ON() variants,
> + * or if it's absolutely unavoidable to crash the system due to
> + * some grave condition, use CRASH_ON():
> + */
> +#define CRASH_ON(condition)	BUG_ON(condition)
> +
>   #endif
>
>   /*
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 89b1df4e72ab..6e0887057398 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -5414,6 +5414,12 @@ sub process {
>   			     "Using $1 should generally have parentheses around the comparison\n" . $herecurr);
>   		}
>
> +# check for use of BUG_ON()
> +		if ($line =~ /\bBUG_ON\s*\(/) {
> +			WARN("BUG_ON",
> +			     "Using BUG_ON() is generally wrong, use WARN_ON() instead - or CRASH_ON() if the kernel absolutely must crash.\n"  . $herecurr);
> +		}
> +
>   # whine mightly about in_atomic
>   		if ($line =~ /\bin_atomic\s*\(/) {
>   			if ($realfile =~ m@...ivers/@) {
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/