linux-kernel - Re: [PATCH] Make WARN_ON/WARN_ON_ONCE no-ops when CONFIG

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]

Message-ID: <20071215065211.GA26579@gondor.apana.org.au>
Date:	Sat, 15 Dec 2007 14:52:11 +0800
From:	Herbert Xu <herbert@...dor.apana.org.au>
To:	Matt Mackall <mpm@...enic.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Dave Jones <davej@...hat.com>
Subject: Re: [PATCH] Make WARN_ON/WARN_ON_ONCE no-ops when CONFIG_BUG is off

On Sat, Dec 15, 2007 at 02:04:49PM +0800, Herbert Xu wrote:
>
> I suppose we'll have to either introduce a new primitive or just
> go back to using BUG_ON.

Let's do the conservative thing and add a new primitive.

[PATCH] Added BARF_ON/BARF_ON_ONCE

The description of CONFIG_BUG clearly states that both BUG and
WARN_ON may be skipped.  However, our actual implementation still
checks the condition on WARN_ON if it's used as part of an if
statement or such.

I tried to compile it away but Matt Mackall pointed out that
people may already be using it in ways that were not intended.
In particular, it may have been used for conditions that are
thought to be possible.

So this patch adds a new pair of macros BARF_ON and BARF_ON_ONCE
that are clearly marked as such to prevent abuse.  The intended
usage model is identical to WARN_ON except that they should only
be used for conditions that are thought to be impossible.  In
other words, only use them to replace BUG_ON's that may be called
by an IRQ handler or within locks.

Signed-off-by: Herbert Xu <herbert@...dor.apana.org.au>

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
index d56fedb..36e565c 100644
--- a/include/asm-generic/bug.h
+++ b/include/asm-generic/bug.h
@@ -43,6 +43,19 @@ struct bug_entry {
 })
 #endif
 
+/*
+ * BARF_ON should only be used in situations which are thought to be
+ * impossible in practice.  In other words, do NOT use it in a place
+ * where you would not use BUG_ON.  It only exists so that the message
+ * gets a chance to be written to disk.
+ *
+ * It should only be used if we can afford to not kill the current
+ * process or the kernel.  So don't use it if we may end up scribbling
+ * over the disk or give people remote root access.
+ */
+#define BARF_ON(condition) WARN_ON(condition)
+#define BARF_ON_ONCE(condition) WARN_ON_ONCE(condition)
+
 #else /* !CONFIG_BUG */
 #ifndef HAVE_ARCH_BUG
 #define BUG()
@@ -58,6 +71,9 @@ struct bug_entry {
 	unlikely(__ret_warn_on);					\
 })
 #endif
+
+#define BARF_ON(condition) ((condition), 0)
+#define BARF_ON_ONCE(condition) BARF_ON(condition)
 #endif
 
 #define WARN_ON_ONCE(condition)	({				\
--
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/