[PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Chen Gang]

The crazy user can unset 'CONFIG_BUG' in menuconfig: "> General setup >
Configure standard kernel features (expert users) > BUG() Support".

But in fact, we always need it, and quite a few of architectures have
already implemented it (e.g. alpha, arc, arm, avr32, blackfin, cris,
frv, ia64, m68k, mips, mn10300, parisc, powerpc, s390, sh, sparc, x86).

And kernel also already has prepared a default effective implementation
for the architectures which is unwilling to implement it by themselves
(e.g. arm64, c6x, h8300, hexagon, m32r, metag, microblaze, openrisc,
score, tile, um, unicore32, xtensa).

So need get rid of 'CONFIG_BUG', and let it always enabled everywhere.


Signed-off-by: Chen Gang <gang.chen@asianux.com>
---
 arch/arm/Kconfig          |    1 -
 arch/avr32/Kconfig        |    1 -
 arch/blackfin/Kconfig     |    1 -
 arch/h8300/Kconfig        |    1 -
 arch/hexagon/Kconfig      |    1 -
 arch/parisc/Kconfig       |    2 --
 arch/powerpc/Kconfig      |    1 -
 arch/s390/Kconfig         |    2 +-
 arch/sh/Kconfig           |    2 +-
 arch/um/Kconfig.common    |    1 -
 arch/x86/Kconfig          |    1 -
 include/asm-generic/bug.h |   29 -----------------------------
 init/Kconfig              |   10 ----------
 lib/Kconfig.debug         |    2 +-
 14 files changed, 3 insertions(+), 52 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index a7fc5ea..ea4a146 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -265,7 +265,6 @@ config PHYS_OFFSET
 
 config GENERIC_BUG
 	def_bool y
-	depends on BUG
 
 source "init/Kconfig"
 
diff --git a/arch/avr32/Kconfig b/arch/avr32/Kconfig
index bdc3558..7c9005a 100644
--- a/arch/avr32/Kconfig
+++ b/arch/avr32/Kconfig
@@ -55,7 +55,6 @@ config GENERIC_CALIBRATE_DELAY
 
 config GENERIC_BUG
 	def_bool y
-	depends on BUG
 
 source "init/Kconfig"
 
diff --git a/arch/blackfin/Kconfig b/arch/blackfin/Kconfig
index a117652..637dc42 100644
--- a/arch/blackfin/Kconfig
+++ b/arch/blackfin/Kconfig
@@ -47,7 +47,6 @@ config GENERIC_CSUM
 
 config GENERIC_BUG
 	def_bool y
-	depends on BUG
 
 config ZONE_DMA
 	def_bool y
diff --git a/arch/h8300/Kconfig b/arch/h8300/Kconfig
index 303e4f9..88848da 100644
--- a/arch/h8300/Kconfig
+++ b/arch/h8300/Kconfig
@@ -56,7 +56,6 @@ config GENERIC_CALIBRATE_DELAY
 
 config GENERIC_BUG
         bool
-        depends on BUG
 
 config TIME_LOW_RES
 	bool
diff --git a/arch/hexagon/Kconfig b/arch/hexagon/Kconfig
index 33a9792..f50cc8f 100644
--- a/arch/hexagon/Kconfig
+++ b/arch/hexagon/Kconfig
@@ -84,7 +84,6 @@ config STACKTRACE_SUPPORT
 
 config GENERIC_BUG
 	def_bool y
-	depends on BUG
 
 menu "Machine selection"
 
diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig
index 6507dab..5de1f8c 100644
--- a/arch/parisc/Kconfig
+++ b/arch/parisc/Kconfig
@@ -10,7 +10,6 @@ config PARISC
 	select RTC_CLASS
 	select RTC_DRV_GENERIC
 	select INIT_ALL_POSSIBLE
-	select BUG
 	select HAVE_PERF_EVENTS
 	select GENERIC_ATOMIC64 if !64BIT
 	select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
@@ -62,7 +61,6 @@ config ARCH_HAS_ILOG2_U64
 config GENERIC_BUG
 	bool
 	default y
-	depends on BUG
 
 config GENERIC_HWEIGHT
 	bool
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index c33e3ad..34f4ca9 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -187,7 +187,6 @@ config AUDIT_ARCH
 config GENERIC_BUG
 	bool
 	default y
-	depends on BUG
 
 config SYS_SUPPORTS_APM_EMULATION
 	default y if PMAC_APM_EMU
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index da183c5..5d7b3db 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -29,7 +29,7 @@ config GENERIC_HWEIGHT
 	def_bool y
 
 config GENERIC_BUG
-	def_bool y if BUG
+	def_bool y
 
 config GENERIC_BUG_RELATIVE_POINTERS
 	def_bool y
diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
index 8c868cf..d555e7f 100644
--- a/arch/sh/Kconfig
+++ b/arch/sh/Kconfig
@@ -84,7 +84,7 @@ config RWSEM_XCHGADD_ALGORITHM
 
 config GENERIC_BUG
 	def_bool y
-	depends on BUG && SUPERH32
+	depends on SUPERH32
 
 config GENERIC_CSUM
 	def_bool y
diff --git a/arch/um/Kconfig.common b/arch/um/Kconfig.common
index bceee66..7aae42a 100644
--- a/arch/um/Kconfig.common
+++ b/arch/um/Kconfig.common
@@ -53,7 +53,6 @@ config GENERIC_CALIBRATE_DELAY
 config GENERIC_BUG
 	bool
 	default y
-	depends on BUG
 
 config HZ
 	int
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 723e42e..a36e1b4 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -166,7 +166,6 @@ config GENERIC_ISA_DMA
 
 config GENERIC_BUG
 	def_bool y
-	depends on BUG
 	select GENERIC_BUG_RELATIVE_POINTERS if X86_64
 
 config GENERIC_BUG_RELATIVE_POINTERS
diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
index 7d10f96..5d50903 100644
--- a/include/asm-generic/bug.h
+++ b/include/asm-generic/bug.h
@@ -12,8 +12,6 @@
 #ifndef __ASSEMBLY__
 #include <linux/kernel.h>
 
-#ifdef CONFIG_BUG
-
 #ifdef CONFIG_GENERIC_BUG
 struct bug_entry {
 #ifndef CONFIG_GENERIC_BUG_RELATIVE_POINTERS
@@ -106,33 +104,6 @@ extern void warn_slowpath_null(const char *file, const int line);
 	unlikely(__ret_warn_on);					\
 })
 
-#else /* !CONFIG_BUG */
-#ifndef HAVE_ARCH_BUG
-#define BUG() do {} while(0)
-#endif
-
-#ifndef HAVE_ARCH_BUG_ON
-#define BUG_ON(condition) do { if (condition) ; } while(0)
-#endif
-
-#ifndef HAVE_ARCH_WARN_ON
-#define WARN_ON(condition) ({						\
-	int __ret_warn_on = !!(condition);				\
-	unlikely(__ret_warn_on);					\
-})
-#endif
-
-#ifndef WARN
-#define WARN(condition, format...) ({					\
-	int __ret_warn_on = !!(condition);				\
-	unlikely(__ret_warn_on);					\
-})
-#endif
-
-#define WARN_TAINT(condition, taint, format...) WARN_ON(condition)
-
-#endif
-
 #define WARN_ON_ONCE(condition)	({				\
 	static bool __section(.data.unlikely) __warned;		\
 	int __ret_warn_once = !!(condition);			\
diff --git a/init/Kconfig b/init/Kconfig
index 7fb26a6..bc1dd49 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1360,16 +1360,6 @@ config PRINTK
 	  very difficult to diagnose system problems, saying N here is
 	  strongly discouraged.
 
-config BUG
-	bool "BUG() support" if EXPERT
-	default y
-	help
-          Disabling this option eliminates support for BUG and WARN, reducing
-          the size of your kernel image and potentially quietly ignoring
-          numerous fatal conditions. You should only consider disabling this
-          option for embedded systems with no facilities for reporting errors.
-          Just say Y.
-
 config ELF_CORE
 	depends on COREDUMP
 	default y
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 566cf2b..54b3251 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -700,7 +700,7 @@ config HAVE_DEBUG_BUGVERBOSE
 
 config DEBUG_BUGVERBOSE
 	bool "Verbose BUG() reporting (adds 70K)" if DEBUG_KERNEL && EXPERT
-	depends on BUG && (GENERIC_BUG || HAVE_DEBUG_BUGVERBOSE)
+	depends on GENERIC_BUG || HAVE_DEBUG_BUGVERBOSE
 	default y
 	help
 	  Say Y here to make BUG() panics output the file name and line number
-- 
1.7.7.6

[PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Chen Gang]

The crazy user can unset 'CONFIG_BUG' in menuconfig: "> General setup >
Configure standard kernel features (expert users) > BUG() Support".

But in fact, we always need it, and quite a few of architectures have
already implemented it (e.g. alpha, arc, arm, avr32, blackfin, cris,
frv, ia64, m68k, mips, mn10300, parisc, powerpc, s390, sh, sparc, x86).

And kernel also already has prepared a default effective implementation
for the architectures which is unwilling to implement it by themselves
(e.g. arm64, c6x, h8300, hexagon, m32r, metag, microblaze, openrisc,
score, tile, um, unicore32, xtensa).

So need get rid of 'CONFIG_BUG', and let it always enabled everywhere.


Signed-off-by: Chen Gang <gang.chen@asianux.com>
---
 arch/arm/Kconfig          |    1 -
 arch/avr32/Kconfig        |    1 -
 arch/blackfin/Kconfig     |    1 -
 arch/h8300/Kconfig        |    1 -
 arch/hexagon/Kconfig      |    1 -
 arch/parisc/Kconfig       |    2 --
 arch/powerpc/Kconfig      |    1 -
 arch/s390/Kconfig         |    2 +-
 arch/sh/Kconfig           |    2 +-
 arch/um/Kconfig.common    |    1 -
 arch/x86/Kconfig          |    1 -
 include/asm-generic/bug.h |   29 -----------------------------
 init/Kconfig              |   10 ----------
 lib/Kconfig.debug         |    2 +-
 14 files changed, 3 insertions(+), 52 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index a7fc5ea..ea4a146 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -265,7 +265,6 @@ config PHYS_OFFSET
 
 config GENERIC_BUG
 	def_bool y
-	depends on BUG
 
 source "init/Kconfig"
 
diff --git a/arch/avr32/Kconfig b/arch/avr32/Kconfig
index bdc3558..7c9005a 100644
--- a/arch/avr32/Kconfig
+++ b/arch/avr32/Kconfig
@@ -55,7 +55,6 @@ config GENERIC_CALIBRATE_DELAY
 
 config GENERIC_BUG
 	def_bool y
-	depends on BUG
 
 source "init/Kconfig"
 
diff --git a/arch/blackfin/Kconfig b/arch/blackfin/Kconfig
index a117652..637dc42 100644
--- a/arch/blackfin/Kconfig
+++ b/arch/blackfin/Kconfig
@@ -47,7 +47,6 @@ config GENERIC_CSUM
 
 config GENERIC_BUG
 	def_bool y
-	depends on BUG
 
 config ZONE_DMA
 	def_bool y
diff --git a/arch/h8300/Kconfig b/arch/h8300/Kconfig
index 303e4f9..88848da 100644
--- a/arch/h8300/Kconfig
+++ b/arch/h8300/Kconfig
@@ -56,7 +56,6 @@ config GENERIC_CALIBRATE_DELAY
 
 config GENERIC_BUG
         bool
-        depends on BUG
 
 config TIME_LOW_RES
 	bool
diff --git a/arch/hexagon/Kconfig b/arch/hexagon/Kconfig
index 33a9792..f50cc8f 100644
--- a/arch/hexagon/Kconfig
+++ b/arch/hexagon/Kconfig
@@ -84,7 +84,6 @@ config STACKTRACE_SUPPORT
 
 config GENERIC_BUG
 	def_bool y
-	depends on BUG
 
 menu "Machine selection"
 
diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig
index 6507dab..5de1f8c 100644
--- a/arch/parisc/Kconfig
+++ b/arch/parisc/Kconfig
@@ -10,7 +10,6 @@ config PARISC
 	select RTC_CLASS
 	select RTC_DRV_GENERIC
 	select INIT_ALL_POSSIBLE
-	select BUG
 	select HAVE_PERF_EVENTS
 	select GENERIC_ATOMIC64 if !64BIT
 	select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
@@ -62,7 +61,6 @@ config ARCH_HAS_ILOG2_U64
 config GENERIC_BUG
 	bool
 	default y
-	depends on BUG
 
 config GENERIC_HWEIGHT
 	bool
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index c33e3ad..34f4ca9 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -187,7 +187,6 @@ config AUDIT_ARCH
 config GENERIC_BUG
 	bool
 	default y
-	depends on BUG
 
 config SYS_SUPPORTS_APM_EMULATION
 	default y if PMAC_APM_EMU
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index da183c5..5d7b3db 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -29,7 +29,7 @@ config GENERIC_HWEIGHT
 	def_bool y
 
 config GENERIC_BUG
-	def_bool y if BUG
+	def_bool y
 
 config GENERIC_BUG_RELATIVE_POINTERS
 	def_bool y
diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
index 8c868cf..d555e7f 100644
--- a/arch/sh/Kconfig
+++ b/arch/sh/Kconfig
@@ -84,7 +84,7 @@ config RWSEM_XCHGADD_ALGORITHM
 
 config GENERIC_BUG
 	def_bool y
-	depends on BUG && SUPERH32
+	depends on SUPERH32
 
 config GENERIC_CSUM
 	def_bool y
diff --git a/arch/um/Kconfig.common b/arch/um/Kconfig.common
index bceee66..7aae42a 100644
--- a/arch/um/Kconfig.common
+++ b/arch/um/Kconfig.common
@@ -53,7 +53,6 @@ config GENERIC_CALIBRATE_DELAY
 config GENERIC_BUG
 	bool
 	default y
-	depends on BUG
 
 config HZ
 	int
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 723e42e..a36e1b4 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -166,7 +166,6 @@ config GENERIC_ISA_DMA
 
 config GENERIC_BUG
 	def_bool y
-	depends on BUG
 	select GENERIC_BUG_RELATIVE_POINTERS if X86_64
 
 config GENERIC_BUG_RELATIVE_POINTERS
diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
index 7d10f96..5d50903 100644
--- a/include/asm-generic/bug.h
+++ b/include/asm-generic/bug.h
@@ -12,8 +12,6 @@
 #ifndef __ASSEMBLY__
 #include <linux/kernel.h>
 
-#ifdef CONFIG_BUG
-
 #ifdef CONFIG_GENERIC_BUG
 struct bug_entry {
 #ifndef CONFIG_GENERIC_BUG_RELATIVE_POINTERS
@@ -106,33 +104,6 @@ extern void warn_slowpath_null(const char *file, const int line);
 	unlikely(__ret_warn_on);					\
 })
 
-#else /* !CONFIG_BUG */
-#ifndef HAVE_ARCH_BUG
-#define BUG() do {} while(0)
-#endif
-
-#ifndef HAVE_ARCH_BUG_ON
-#define BUG_ON(condition) do { if (condition) ; } while(0)
-#endif
-
-#ifndef HAVE_ARCH_WARN_ON
-#define WARN_ON(condition) ({						\
-	int __ret_warn_on = !!(condition);				\
-	unlikely(__ret_warn_on);					\
-})
-#endif
-
-#ifndef WARN
-#define WARN(condition, format...) ({					\
-	int __ret_warn_on = !!(condition);				\
-	unlikely(__ret_warn_on);					\
-})
-#endif
-
-#define WARN_TAINT(condition, taint, format...) WARN_ON(condition)
-
-#endif
-
 #define WARN_ON_ONCE(condition)	({				\
 	static bool __section(.data.unlikely) __warned;		\
 	int __ret_warn_once = !!(condition);			\
diff --git a/init/Kconfig b/init/Kconfig
index 7fb26a6..bc1dd49 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1360,16 +1360,6 @@ config PRINTK
 	  very difficult to diagnose system problems, saying N here is
 	  strongly discouraged.
 
-config BUG
-	bool "BUG() support" if EXPERT
-	default y
-	help
-          Disabling this option eliminates support for BUG and WARN, reducing
-          the size of your kernel image and potentially quietly ignoring
-          numerous fatal conditions. You should only consider disabling this
-          option for embedded systems with no facilities for reporting errors.
-          Just say Y.
-
 config ELF_CORE
 	depends on COREDUMP
 	default y
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 566cf2b..54b3251 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -700,7 +700,7 @@ config HAVE_DEBUG_BUGVERBOSE
 
 config DEBUG_BUGVERBOSE
 	bool "Verbose BUG() reporting (adds 70K)" if DEBUG_KERNEL && EXPERT
-	depends on BUG && (GENERIC_BUG || HAVE_DEBUG_BUGVERBOSE)
+	depends on GENERIC_BUG || HAVE_DEBUG_BUGVERBOSE
 	default y
 	help
 	  Say Y here to make BUG() panics output the file name and line number
-- 
1.7.7.6

[PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Chen Gang]

The crazy user can unset 'CONFIG_BUG' in menuconfig: "> General setup >
Configure standard kernel features (expert users) > BUG() Support".

But in fact, we always need it, and quite a few of architectures have
already implemented it (e.g. alpha, arc, arm, avr32, blackfin, cris,
frv, ia64, m68k, mips, mn10300, parisc, powerpc, s390, sh, sparc, x86).

And kernel also already has prepared a default effective implementation
for the architectures which is unwilling to implement it by themselves
(e.g. arm64, c6x, h8300, hexagon, m32r, metag, microblaze, openrisc,
score, tile, um, unicore32, xtensa).

So need get rid of 'CONFIG_BUG', and let it always enabled everywhere.


Signed-off-by: Chen Gang <gang.chen@asianux.com>
---
 arch/arm/Kconfig          |    1 -
 arch/avr32/Kconfig        |    1 -
 arch/blackfin/Kconfig     |    1 -
 arch/h8300/Kconfig        |    1 -
 arch/hexagon/Kconfig      |    1 -
 arch/parisc/Kconfig       |    2 --
 arch/powerpc/Kconfig      |    1 -
 arch/s390/Kconfig         |    2 +-
 arch/sh/Kconfig           |    2 +-
 arch/um/Kconfig.common    |    1 -
 arch/x86/Kconfig          |    1 -
 include/asm-generic/bug.h |   29 -----------------------------
 init/Kconfig              |   10 ----------
 lib/Kconfig.debug         |    2 +-
 14 files changed, 3 insertions(+), 52 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index a7fc5ea..ea4a146 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -265,7 +265,6 @@ config PHYS_OFFSET
 
 config GENERIC_BUG
 	def_bool y
-	depends on BUG
 
 source "init/Kconfig"
 
diff --git a/arch/avr32/Kconfig b/arch/avr32/Kconfig
index bdc3558..7c9005a 100644
--- a/arch/avr32/Kconfig
+++ b/arch/avr32/Kconfig
@@ -55,7 +55,6 @@ config GENERIC_CALIBRATE_DELAY
 
 config GENERIC_BUG
 	def_bool y
-	depends on BUG
 
 source "init/Kconfig"
 
diff --git a/arch/blackfin/Kconfig b/arch/blackfin/Kconfig
index a117652..637dc42 100644
--- a/arch/blackfin/Kconfig
+++ b/arch/blackfin/Kconfig
@@ -47,7 +47,6 @@ config GENERIC_CSUM
 
 config GENERIC_BUG
 	def_bool y
-	depends on BUG
 
 config ZONE_DMA
 	def_bool y
diff --git a/arch/h8300/Kconfig b/arch/h8300/Kconfig
index 303e4f9..88848da 100644
--- a/arch/h8300/Kconfig
+++ b/arch/h8300/Kconfig
@@ -56,7 +56,6 @@ config GENERIC_CALIBRATE_DELAY
 
 config GENERIC_BUG
         bool
-        depends on BUG
 
 config TIME_LOW_RES
 	bool
diff --git a/arch/hexagon/Kconfig b/arch/hexagon/Kconfig
index 33a9792..f50cc8f 100644
--- a/arch/hexagon/Kconfig
+++ b/arch/hexagon/Kconfig
@@ -84,7 +84,6 @@ config STACKTRACE_SUPPORT
 
 config GENERIC_BUG
 	def_bool y
-	depends on BUG
 
 menu "Machine selection"
 
diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig
index 6507dab..5de1f8c 100644
--- a/arch/parisc/Kconfig
+++ b/arch/parisc/Kconfig
@@ -10,7 +10,6 @@ config PARISC
 	select RTC_CLASS
 	select RTC_DRV_GENERIC
 	select INIT_ALL_POSSIBLE
-	select BUG
 	select HAVE_PERF_EVENTS
 	select GENERIC_ATOMIC64 if !64BIT
 	select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
@@ -62,7 +61,6 @@ config ARCH_HAS_ILOG2_U64
 config GENERIC_BUG
 	bool
 	default y
-	depends on BUG
 
 config GENERIC_HWEIGHT
 	bool
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index c33e3ad..34f4ca9 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -187,7 +187,6 @@ config AUDIT_ARCH
 config GENERIC_BUG
 	bool
 	default y
-	depends on BUG
 
 config SYS_SUPPORTS_APM_EMULATION
 	default y if PMAC_APM_EMU
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index da183c5..5d7b3db 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -29,7 +29,7 @@ config GENERIC_HWEIGHT
 	def_bool y
 
 config GENERIC_BUG
-	def_bool y if BUG
+	def_bool y
 
 config GENERIC_BUG_RELATIVE_POINTERS
 	def_bool y
diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
index 8c868cf..d555e7f 100644
--- a/arch/sh/Kconfig
+++ b/arch/sh/Kconfig
@@ -84,7 +84,7 @@ config RWSEM_XCHGADD_ALGORITHM
 
 config GENERIC_BUG
 	def_bool y
-	depends on BUG && SUPERH32
+	depends on SUPERH32
 
 config GENERIC_CSUM
 	def_bool y
diff --git a/arch/um/Kconfig.common b/arch/um/Kconfig.common
index bceee66..7aae42a 100644
--- a/arch/um/Kconfig.common
+++ b/arch/um/Kconfig.common
@@ -53,7 +53,6 @@ config GENERIC_CALIBRATE_DELAY
 config GENERIC_BUG
 	bool
 	default y
-	depends on BUG
 
 config HZ
 	int
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 723e42e..a36e1b4 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -166,7 +166,6 @@ config GENERIC_ISA_DMA
 
 config GENERIC_BUG
 	def_bool y
-	depends on BUG
 	select GENERIC_BUG_RELATIVE_POINTERS if X86_64
 
 config GENERIC_BUG_RELATIVE_POINTERS
diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
index 7d10f96..5d50903 100644
--- a/include/asm-generic/bug.h
+++ b/include/asm-generic/bug.h
@@ -12,8 +12,6 @@
 #ifndef __ASSEMBLY__
 #include <linux/kernel.h>
 
-#ifdef CONFIG_BUG
-
 #ifdef CONFIG_GENERIC_BUG
 struct bug_entry {
 #ifndef CONFIG_GENERIC_BUG_RELATIVE_POINTERS
@@ -106,33 +104,6 @@ extern void warn_slowpath_null(const char *file, const int line);
 	unlikely(__ret_warn_on);					\
 })
 
-#else /* !CONFIG_BUG */
-#ifndef HAVE_ARCH_BUG
-#define BUG() do {} while(0)
-#endif
-
-#ifndef HAVE_ARCH_BUG_ON
-#define BUG_ON(condition) do { if (condition) ; } while(0)
-#endif
-
-#ifndef HAVE_ARCH_WARN_ON
-#define WARN_ON(condition) ({						\
-	int __ret_warn_on = !!(condition);				\
-	unlikely(__ret_warn_on);					\
-})
-#endif
-
-#ifndef WARN
-#define WARN(condition, format...) ({					\
-	int __ret_warn_on = !!(condition);				\
-	unlikely(__ret_warn_on);					\
-})
-#endif
-
-#define WARN_TAINT(condition, taint, format...) WARN_ON(condition)
-
-#endif
-
 #define WARN_ON_ONCE(condition)	({				\
 	static bool __section(.data.unlikely) __warned;		\
 	int __ret_warn_once = !!(condition);			\
diff --git a/init/Kconfig b/init/Kconfig
index 7fb26a6..bc1dd49 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1360,16 +1360,6 @@ config PRINTK
 	  very difficult to diagnose system problems, saying N here is
 	  strongly discouraged.
 
-config BUG
-	bool "BUG() support" if EXPERT
-	default y
-	help
-          Disabling this option eliminates support for BUG and WARN, reducing
-          the size of your kernel image and potentially quietly ignoring
-          numerous fatal conditions. You should only consider disabling this
-          option for embedded systems with no facilities for reporting errors.
-          Just say Y.
-
 config ELF_CORE
 	depends on COREDUMP
 	default y
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 566cf2b..54b3251 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -700,7 +700,7 @@ config HAVE_DEBUG_BUGVERBOSE
 
 config DEBUG_BUGVERBOSE
 	bool "Verbose BUG() reporting (adds 70K)" if DEBUG_KERNEL && EXPERT
-	depends on BUG && (GENERIC_BUG || HAVE_DEBUG_BUGVERBOSE)
+	depends on GENERIC_BUG || HAVE_DEBUG_BUGVERBOSE
 	default y
 	help
 	  Say Y here to make BUG() panics output the file name and line number
-- 
1.7.7.6

[PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Chen Gang]

The crazy user can unset 'CONFIG_BUG' in menuconfig: "> General setup >
Configure standard kernel features (expert users) > BUG() Support".

But in fact, we always need it, and quite a few of architectures have
already implemented it (e.g. alpha, arc, arm, avr32, blackfin, cris,
frv, ia64, m68k, mips, mn10300, parisc, powerpc, s390, sh, sparc, x86).

And kernel also already has prepared a default effective implementation
for the architectures which is unwilling to implement it by themselves
(e.g. arm64, c6x, h8300, hexagon, m32r, metag, microblaze, openrisc,
score, tile, um, unicore32, xtensa).

So need get rid of 'CONFIG_BUG', and let it always enabled everywhere.


Signed-off-by: Chen Gang <gang.chen@asianux.com>
---
 arch/arm/Kconfig          |    1 -
 arch/avr32/Kconfig        |    1 -
 arch/blackfin/Kconfig     |    1 -
 arch/h8300/Kconfig        |    1 -
 arch/hexagon/Kconfig      |    1 -
 arch/parisc/Kconfig       |    2 --
 arch/powerpc/Kconfig      |    1 -
 arch/s390/Kconfig         |    2 +-
 arch/sh/Kconfig           |    2 +-
 arch/um/Kconfig.common    |    1 -
 arch/x86/Kconfig          |    1 -
 include/asm-generic/bug.h |   29 -----------------------------
 init/Kconfig              |   10 ----------
 lib/Kconfig.debug         |    2 +-
 14 files changed, 3 insertions(+), 52 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index a7fc5ea..ea4a146 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -265,7 +265,6 @@ config PHYS_OFFSET
 
 config GENERIC_BUG
 	def_bool y
-	depends on BUG
 
 source "init/Kconfig"
 
diff --git a/arch/avr32/Kconfig b/arch/avr32/Kconfig
index bdc3558..7c9005a 100644
--- a/arch/avr32/Kconfig
+++ b/arch/avr32/Kconfig
@@ -55,7 +55,6 @@ config GENERIC_CALIBRATE_DELAY
 
 config GENERIC_BUG
 	def_bool y
-	depends on BUG
 
 source "init/Kconfig"
 
diff --git a/arch/blackfin/Kconfig b/arch/blackfin/Kconfig
index a117652..637dc42 100644
--- a/arch/blackfin/Kconfig
+++ b/arch/blackfin/Kconfig
@@ -47,7 +47,6 @@ config GENERIC_CSUM
 
 config GENERIC_BUG
 	def_bool y
-	depends on BUG
 
 config ZONE_DMA
 	def_bool y
diff --git a/arch/h8300/Kconfig b/arch/h8300/Kconfig
index 303e4f9..88848da 100644
--- a/arch/h8300/Kconfig
+++ b/arch/h8300/Kconfig
@@ -56,7 +56,6 @@ config GENERIC_CALIBRATE_DELAY
 
 config GENERIC_BUG
         bool
-        depends on BUG
 
 config TIME_LOW_RES
 	bool
diff --git a/arch/hexagon/Kconfig b/arch/hexagon/Kconfig
index 33a9792..f50cc8f 100644
--- a/arch/hexagon/Kconfig
+++ b/arch/hexagon/Kconfig
@@ -84,7 +84,6 @@ config STACKTRACE_SUPPORT
 
 config GENERIC_BUG
 	def_bool y
-	depends on BUG
 
 menu "Machine selection"
 
diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig
index 6507dab..5de1f8c 100644
--- a/arch/parisc/Kconfig
+++ b/arch/parisc/Kconfig
@@ -10,7 +10,6 @@ config PARISC
 	select RTC_CLASS
 	select RTC_DRV_GENERIC
 	select INIT_ALL_POSSIBLE
-	select BUG
 	select HAVE_PERF_EVENTS
 	select GENERIC_ATOMIC64 if !64BIT
 	select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
@@ -62,7 +61,6 @@ config ARCH_HAS_ILOG2_U64
 config GENERIC_BUG
 	bool
 	default y
-	depends on BUG
 
 config GENERIC_HWEIGHT
 	bool
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index c33e3ad..34f4ca9 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -187,7 +187,6 @@ config AUDIT_ARCH
 config GENERIC_BUG
 	bool
 	default y
-	depends on BUG
 
 config SYS_SUPPORTS_APM_EMULATION
 	default y if PMAC_APM_EMU
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index da183c5..5d7b3db 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -29,7 +29,7 @@ config GENERIC_HWEIGHT
 	def_bool y
 
 config GENERIC_BUG
-	def_bool y if BUG
+	def_bool y
 
 config GENERIC_BUG_RELATIVE_POINTERS
 	def_bool y
diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
index 8c868cf..d555e7f 100644
--- a/arch/sh/Kconfig
+++ b/arch/sh/Kconfig
@@ -84,7 +84,7 @@ config RWSEM_XCHGADD_ALGORITHM
 
 config GENERIC_BUG
 	def_bool y
-	depends on BUG && SUPERH32
+	depends on SUPERH32
 
 config GENERIC_CSUM
 	def_bool y
diff --git a/arch/um/Kconfig.common b/arch/um/Kconfig.common
index bceee66..7aae42a 100644
--- a/arch/um/Kconfig.common
+++ b/arch/um/Kconfig.common
@@ -53,7 +53,6 @@ config GENERIC_CALIBRATE_DELAY
 config GENERIC_BUG
 	bool
 	default y
-	depends on BUG
 
 config HZ
 	int
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 723e42e..a36e1b4 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -166,7 +166,6 @@ config GENERIC_ISA_DMA
 
 config GENERIC_BUG
 	def_bool y
-	depends on BUG
 	select GENERIC_BUG_RELATIVE_POINTERS if X86_64
 
 config GENERIC_BUG_RELATIVE_POINTERS
diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
index 7d10f96..5d50903 100644
--- a/include/asm-generic/bug.h
+++ b/include/asm-generic/bug.h
@@ -12,8 +12,6 @@
 #ifndef __ASSEMBLY__
 #include <linux/kernel.h>
 
-#ifdef CONFIG_BUG
-
 #ifdef CONFIG_GENERIC_BUG
 struct bug_entry {
 #ifndef CONFIG_GENERIC_BUG_RELATIVE_POINTERS
@@ -106,33 +104,6 @@ extern void warn_slowpath_null(const char *file, const int line);
 	unlikely(__ret_warn_on);					\
 })
 
-#else /* !CONFIG_BUG */
-#ifndef HAVE_ARCH_BUG
-#define BUG() do {} while(0)
-#endif
-
-#ifndef HAVE_ARCH_BUG_ON
-#define BUG_ON(condition) do { if (condition) ; } while(0)
-#endif
-
-#ifndef HAVE_ARCH_WARN_ON
-#define WARN_ON(condition) ({						\
-	int __ret_warn_on = !!(condition);				\
-	unlikely(__ret_warn_on);					\
-})
-#endif
-
-#ifndef WARN
-#define WARN(condition, format...) ({					\
-	int __ret_warn_on = !!(condition);				\
-	unlikely(__ret_warn_on);					\
-})
-#endif
-
-#define WARN_TAINT(condition, taint, format...) WARN_ON(condition)
-
-#endif
-
 #define WARN_ON_ONCE(condition)	({				\
 	static bool __section(.data.unlikely) __warned;		\
 	int __ret_warn_once = !!(condition);			\
diff --git a/init/Kconfig b/init/Kconfig
index 7fb26a6..bc1dd49 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1360,16 +1360,6 @@ config PRINTK
 	  very difficult to diagnose system problems, saying N here is
 	  strongly discouraged.
 
-config BUG
-	bool "BUG() support" if EXPERT
-	default y
-	help
-          Disabling this option eliminates support for BUG and WARN, reducing
-          the size of your kernel image and potentially quietly ignoring
-          numerous fatal conditions. You should only consider disabling this
-          option for embedded systems with no facilities for reporting errors.
-          Just say Y.
-
 config ELF_CORE
 	depends on COREDUMP
 	default y
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 566cf2b..54b3251 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -700,7 +700,7 @@ config HAVE_DEBUG_BUGVERBOSE
 
 config DEBUG_BUGVERBOSE
 	bool "Verbose BUG() reporting (adds 70K)" if DEBUG_KERNEL && EXPERT
-	depends on BUG && (GENERIC_BUG || HAVE_DEBUG_BUGVERBOSE)
+	depends on GENERIC_BUG || HAVE_DEBUG_BUGVERBOSE
 	default y
 	help
 	  Say Y here to make BUG() panics output the file name and line number
-- 
1.7.7.6

[PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Chen Gang]

The crazy user can unset 'CONFIG_BUG' in menuconfig: "> General setup >
Configure standard kernel features (expert users) > BUG() Support".

But in fact, we always need it, and quite a few of architectures have
already implemented it (e.g. alpha, arc, arm, avr32, blackfin, cris,
frv, ia64, m68k, mips, mn10300, parisc, powerpc, s390, sh, sparc, x86).

And kernel also already has prepared a default effective implementation
for the architectures which is unwilling to implement it by themselves
(e.g. arm64, c6x, h8300, hexagon, m32r, metag, microblaze, openrisc,
score, tile, um, unicore32, xtensa).

So need get rid of 'CONFIG_BUG', and let it always enabled everywhere.


Signed-off-by: Chen Gang <gang.chen@asianux.com>
---
 arch/arm/Kconfig          |    1 -
 arch/avr32/Kconfig        |    1 -
 arch/blackfin/Kconfig     |    1 -
 arch/h8300/Kconfig        |    1 -
 arch/hexagon/Kconfig      |    1 -
 arch/parisc/Kconfig       |    2 --
 arch/powerpc/Kconfig      |    1 -
 arch/s390/Kconfig         |    2 +-
 arch/sh/Kconfig           |    2 +-
 arch/um/Kconfig.common    |    1 -
 arch/x86/Kconfig          |    1 -
 include/asm-generic/bug.h |   29 -----------------------------
 init/Kconfig              |   10 ----------
 lib/Kconfig.debug         |    2 +-
 14 files changed, 3 insertions(+), 52 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index a7fc5ea..ea4a146 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -265,7 +265,6 @@ config PHYS_OFFSET
 
 config GENERIC_BUG
 	def_bool y
-	depends on BUG
 
 source "init/Kconfig"
 
diff --git a/arch/avr32/Kconfig b/arch/avr32/Kconfig
index bdc3558..7c9005a 100644
--- a/arch/avr32/Kconfig
+++ b/arch/avr32/Kconfig
@@ -55,7 +55,6 @@ config GENERIC_CALIBRATE_DELAY
 
 config GENERIC_BUG
 	def_bool y
-	depends on BUG
 
 source "init/Kconfig"
 
diff --git a/arch/blackfin/Kconfig b/arch/blackfin/Kconfig
index a117652..637dc42 100644
--- a/arch/blackfin/Kconfig
+++ b/arch/blackfin/Kconfig
@@ -47,7 +47,6 @@ config GENERIC_CSUM
 
 config GENERIC_BUG
 	def_bool y
-	depends on BUG
 
 config ZONE_DMA
 	def_bool y
diff --git a/arch/h8300/Kconfig b/arch/h8300/Kconfig
index 303e4f9..88848da 100644
--- a/arch/h8300/Kconfig
+++ b/arch/h8300/Kconfig
@@ -56,7 +56,6 @@ config GENERIC_CALIBRATE_DELAY
 
 config GENERIC_BUG
         bool
-        depends on BUG
 
 config TIME_LOW_RES
 	bool
diff --git a/arch/hexagon/Kconfig b/arch/hexagon/Kconfig
index 33a9792..f50cc8f 100644
--- a/arch/hexagon/Kconfig
+++ b/arch/hexagon/Kconfig
@@ -84,7 +84,6 @@ config STACKTRACE_SUPPORT
 
 config GENERIC_BUG
 	def_bool y
-	depends on BUG
 
 menu "Machine selection"
 
diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig
index 6507dab..5de1f8c 100644
--- a/arch/parisc/Kconfig
+++ b/arch/parisc/Kconfig
@@ -10,7 +10,6 @@ config PARISC
 	select RTC_CLASS
 	select RTC_DRV_GENERIC
 	select INIT_ALL_POSSIBLE
-	select BUG
 	select HAVE_PERF_EVENTS
 	select GENERIC_ATOMIC64 if !64BIT
 	select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
@@ -62,7 +61,6 @@ config ARCH_HAS_ILOG2_U64
 config GENERIC_BUG
 	bool
 	default y
-	depends on BUG
 
 config GENERIC_HWEIGHT
 	bool
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index c33e3ad..34f4ca9 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -187,7 +187,6 @@ config AUDIT_ARCH
 config GENERIC_BUG
 	bool
 	default y
-	depends on BUG
 
 config SYS_SUPPORTS_APM_EMULATION
 	default y if PMAC_APM_EMU
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index da183c5..5d7b3db 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -29,7 +29,7 @@ config GENERIC_HWEIGHT
 	def_bool y
 
 config GENERIC_BUG
-	def_bool y if BUG
+	def_bool y
 
 config GENERIC_BUG_RELATIVE_POINTERS
 	def_bool y
diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
index 8c868cf..d555e7f 100644
--- a/arch/sh/Kconfig
+++ b/arch/sh/Kconfig
@@ -84,7 +84,7 @@ config RWSEM_XCHGADD_ALGORITHM
 
 config GENERIC_BUG
 	def_bool y
-	depends on BUG && SUPERH32
+	depends on SUPERH32
 
 config GENERIC_CSUM
 	def_bool y
diff --git a/arch/um/Kconfig.common b/arch/um/Kconfig.common
index bceee66..7aae42a 100644
--- a/arch/um/Kconfig.common
+++ b/arch/um/Kconfig.common
@@ -53,7 +53,6 @@ config GENERIC_CALIBRATE_DELAY
 config GENERIC_BUG
 	bool
 	default y
-	depends on BUG
 
 config HZ
 	int
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 723e42e..a36e1b4 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -166,7 +166,6 @@ config GENERIC_ISA_DMA
 
 config GENERIC_BUG
 	def_bool y
-	depends on BUG
 	select GENERIC_BUG_RELATIVE_POINTERS if X86_64
 
 config GENERIC_BUG_RELATIVE_POINTERS
diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
index 7d10f96..5d50903 100644
--- a/include/asm-generic/bug.h
+++ b/include/asm-generic/bug.h
@@ -12,8 +12,6 @@
 #ifndef __ASSEMBLY__
 #include <linux/kernel.h>
 
-#ifdef CONFIG_BUG
-
 #ifdef CONFIG_GENERIC_BUG
 struct bug_entry {
 #ifndef CONFIG_GENERIC_BUG_RELATIVE_POINTERS
@@ -106,33 +104,6 @@ extern void warn_slowpath_null(const char *file, const int line);
 	unlikely(__ret_warn_on);					\
 })
 
-#else /* !CONFIG_BUG */
-#ifndef HAVE_ARCH_BUG
-#define BUG() do {} while(0)
-#endif
-
-#ifndef HAVE_ARCH_BUG_ON
-#define BUG_ON(condition) do { if (condition) ; } while(0)
-#endif
-
-#ifndef HAVE_ARCH_WARN_ON
-#define WARN_ON(condition) ({						\
-	int __ret_warn_on = !!(condition);				\
-	unlikely(__ret_warn_on);					\
-})
-#endif
-
-#ifndef WARN
-#define WARN(condition, format...) ({					\
-	int __ret_warn_on = !!(condition);				\
-	unlikely(__ret_warn_on);					\
-})
-#endif
-
-#define WARN_TAINT(condition, taint, format...) WARN_ON(condition)
-
-#endif
-
 #define WARN_ON_ONCE(condition)	({				\
 	static bool __section(.data.unlikely) __warned;		\
 	int __ret_warn_once = !!(condition);			\
diff --git a/init/Kconfig b/init/Kconfig
index 7fb26a6..bc1dd49 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1360,16 +1360,6 @@ config PRINTK
 	  very difficult to diagnose system problems, saying N here is
 	  strongly discouraged.
 
-config BUG
-	bool "BUG() support" if EXPERT
-	default y
-	help
-          Disabling this option eliminates support for BUG and WARN, reducing
-          the size of your kernel image and potentially quietly ignoring
-          numerous fatal conditions. You should only consider disabling this
-          option for embedded systems with no facilities for reporting errors.
-          Just say Y.
-
 config ELF_CORE
 	depends on COREDUMP
 	default y
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 566cf2b..54b3251 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -700,7 +700,7 @@ config HAVE_DEBUG_BUGVERBOSE
 
 config DEBUG_BUGVERBOSE
 	bool "Verbose BUG() reporting (adds 70K)" if DEBUG_KERNEL && EXPERT
-	depends on BUG && (GENERIC_BUG || HAVE_DEBUG_BUGVERBOSE)
+	depends on GENERIC_BUG || HAVE_DEBUG_BUGVERBOSE
 	default y
 	help
 	  Say Y here to make BUG() panics output the file name and line number
-- 
1.7.7.6

[PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Chen Gang]

The crazy user can unset 'CONFIG_BUG' in menuconfig: "> General setup >
Configure standard kernel features (expert users) > BUG() Support".

But in fact, we always need it, and quite a few of architectures have
already implemented it (e.g. alpha, arc, arm, avr32, blackfin, cris,
frv, ia64, m68k, mips, mn10300, parisc, powerpc, s390, sh, sparc, x86).

And kernel also already has prepared a default effective implementation
for the architectures which is unwilling to implement it by themselves
(e.g. arm64, c6x, h8300, hexagon, m32r, metag, microblaze, openrisc,
score, tile, um, unicore32, xtensa).

So need get rid of 'CONFIG_BUG', and let it always enabled everywhere.


Signed-off-by: Chen Gang <gang.chen@asianux.com>
---
 arch/arm/Kconfig          |    1 -
 arch/avr32/Kconfig        |    1 -
 arch/blackfin/Kconfig     |    1 -
 arch/h8300/Kconfig        |    1 -
 arch/hexagon/Kconfig      |    1 -
 arch/parisc/Kconfig       |    2 --
 arch/powerpc/Kconfig      |    1 -
 arch/s390/Kconfig         |    2 +-
 arch/sh/Kconfig           |    2 +-
 arch/um/Kconfig.common    |    1 -
 arch/x86/Kconfig          |    1 -
 include/asm-generic/bug.h |   29 -----------------------------
 init/Kconfig              |   10 ----------
 lib/Kconfig.debug         |    2 +-
 14 files changed, 3 insertions(+), 52 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index a7fc5ea..ea4a146 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -265,7 +265,6 @@ config PHYS_OFFSET
 
 config GENERIC_BUG
 	def_bool y
-	depends on BUG
 
 source "init/Kconfig"
 
diff --git a/arch/avr32/Kconfig b/arch/avr32/Kconfig
index bdc3558..7c9005a 100644
--- a/arch/avr32/Kconfig
+++ b/arch/avr32/Kconfig
@@ -55,7 +55,6 @@ config GENERIC_CALIBRATE_DELAY
 
 config GENERIC_BUG
 	def_bool y
-	depends on BUG
 
 source "init/Kconfig"
 
diff --git a/arch/blackfin/Kconfig b/arch/blackfin/Kconfig
index a117652..637dc42 100644
--- a/arch/blackfin/Kconfig
+++ b/arch/blackfin/Kconfig
@@ -47,7 +47,6 @@ config GENERIC_CSUM
 
 config GENERIC_BUG
 	def_bool y
-	depends on BUG
 
 config ZONE_DMA
 	def_bool y
diff --git a/arch/h8300/Kconfig b/arch/h8300/Kconfig
index 303e4f9..88848da 100644
--- a/arch/h8300/Kconfig
+++ b/arch/h8300/Kconfig
@@ -56,7 +56,6 @@ config GENERIC_CALIBRATE_DELAY
 
 config GENERIC_BUG
         bool
-        depends on BUG
 
 config TIME_LOW_RES
 	bool
diff --git a/arch/hexagon/Kconfig b/arch/hexagon/Kconfig
index 33a9792..f50cc8f 100644
--- a/arch/hexagon/Kconfig
+++ b/arch/hexagon/Kconfig
@@ -84,7 +84,6 @@ config STACKTRACE_SUPPORT
 
 config GENERIC_BUG
 	def_bool y
-	depends on BUG
 
 menu "Machine selection"
 
diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig
index 6507dab..5de1f8c 100644
--- a/arch/parisc/Kconfig
+++ b/arch/parisc/Kconfig
@@ -10,7 +10,6 @@ config PARISC
 	select RTC_CLASS
 	select RTC_DRV_GENERIC
 	select INIT_ALL_POSSIBLE
-	select BUG
 	select HAVE_PERF_EVENTS
 	select GENERIC_ATOMIC64 if !64BIT
 	select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
@@ -62,7 +61,6 @@ config ARCH_HAS_ILOG2_U64
 config GENERIC_BUG
 	bool
 	default y
-	depends on BUG
 
 config GENERIC_HWEIGHT
 	bool
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index c33e3ad..34f4ca9 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -187,7 +187,6 @@ config AUDIT_ARCH
 config GENERIC_BUG
 	bool
 	default y
-	depends on BUG
 
 config SYS_SUPPORTS_APM_EMULATION
 	default y if PMAC_APM_EMU
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index da183c5..5d7b3db 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -29,7 +29,7 @@ config GENERIC_HWEIGHT
 	def_bool y
 
 config GENERIC_BUG
-	def_bool y if BUG
+	def_bool y
 
 config GENERIC_BUG_RELATIVE_POINTERS
 	def_bool y
diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
index 8c868cf..d555e7f 100644
--- a/arch/sh/Kconfig
+++ b/arch/sh/Kconfig
@@ -84,7 +84,7 @@ config RWSEM_XCHGADD_ALGORITHM
 
 config GENERIC_BUG
 	def_bool y
-	depends on BUG && SUPERH32
+	depends on SUPERH32
 
 config GENERIC_CSUM
 	def_bool y
diff --git a/arch/um/Kconfig.common b/arch/um/Kconfig.common
index bceee66..7aae42a 100644
--- a/arch/um/Kconfig.common
+++ b/arch/um/Kconfig.common
@@ -53,7 +53,6 @@ config GENERIC_CALIBRATE_DELAY
 config GENERIC_BUG
 	bool
 	default y
-	depends on BUG
 
 config HZ
 	int
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 723e42e..a36e1b4 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -166,7 +166,6 @@ config GENERIC_ISA_DMA
 
 config GENERIC_BUG
 	def_bool y
-	depends on BUG
 	select GENERIC_BUG_RELATIVE_POINTERS if X86_64
 
 config GENERIC_BUG_RELATIVE_POINTERS
diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
index 7d10f96..5d50903 100644
--- a/include/asm-generic/bug.h
+++ b/include/asm-generic/bug.h
@@ -12,8 +12,6 @@
 #ifndef __ASSEMBLY__
 #include <linux/kernel.h>
 
-#ifdef CONFIG_BUG
-
 #ifdef CONFIG_GENERIC_BUG
 struct bug_entry {
 #ifndef CONFIG_GENERIC_BUG_RELATIVE_POINTERS
@@ -106,33 +104,6 @@ extern void warn_slowpath_null(const char *file, const int line);
 	unlikely(__ret_warn_on);					\
 })
 
-#else /* !CONFIG_BUG */
-#ifndef HAVE_ARCH_BUG
-#define BUG() do {} while(0)
-#endif
-
-#ifndef HAVE_ARCH_BUG_ON
-#define BUG_ON(condition) do { if (condition) ; } while(0)
-#endif
-
-#ifndef HAVE_ARCH_WARN_ON
-#define WARN_ON(condition) ({						\
-	int __ret_warn_on = !!(condition);				\
-	unlikely(__ret_warn_on);					\
-})
-#endif
-
-#ifndef WARN
-#define WARN(condition, format...) ({					\
-	int __ret_warn_on = !!(condition);				\
-	unlikely(__ret_warn_on);					\
-})
-#endif
-
-#define WARN_TAINT(condition, taint, format...) WARN_ON(condition)
-
-#endif
-
 #define WARN_ON_ONCE(condition)	({				\
 	static bool __section(.data.unlikely) __warned;		\
 	int __ret_warn_once = !!(condition);			\
diff --git a/init/Kconfig b/init/Kconfig
index 7fb26a6..bc1dd49 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1360,16 +1360,6 @@ config PRINTK
 	  very difficult to diagnose system problems, saying N here is
 	  strongly discouraged.
 
-config BUG
-	bool "BUG() support" if EXPERT
-	default y
-	help
-          Disabling this option eliminates support for BUG and WARN, reducing
-          the size of your kernel image and potentially quietly ignoring
-          numerous fatal conditions. You should only consider disabling this
-          option for embedded systems with no facilities for reporting errors.
-          Just say Y.
-
 config ELF_CORE
 	depends on COREDUMP
 	default y
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 566cf2b..54b3251 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -700,7 +700,7 @@ config HAVE_DEBUG_BUGVERBOSE
 
 config DEBUG_BUGVERBOSE
 	bool "Verbose BUG() reporting (adds 70K)" if DEBUG_KERNEL && EXPERT
-	depends on BUG && (GENERIC_BUG || HAVE_DEBUG_BUGVERBOSE)
+	depends on GENERIC_BUG || HAVE_DEBUG_BUGVERBOSE
 	default y
 	help
 	  Say Y here to make BUG() panics output the file name and line number
-- 
1.7.7.6

[PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Chen Gang]

The crazy user can unset 'CONFIG_BUG' in menuconfig: "> General setup >
Configure standard kernel features (expert users) > BUG() Support".

But in fact, we always need it, and quite a few of architectures have
already implemented it (e.g. alpha, arc, arm, avr32, blackfin, cris,
frv, ia64, m68k, mips, mn10300, parisc, powerpc, s390, sh, sparc, x86).

And kernel also already has prepared a default effective implementation
for the architectures which is unwilling to implement it by themselves
(e.g. arm64, c6x, h8300, hexagon, m32r, metag, microblaze, openrisc,
score, tile, um, unicore32, xtensa).

So need get rid of 'CONFIG_BUG', and let it always enabled everywhere.


Signed-off-by: Chen Gang <gang.chen@asianux.com>
---
 arch/arm/Kconfig          |    1 -
 arch/avr32/Kconfig        |    1 -
 arch/blackfin/Kconfig     |    1 -
 arch/h8300/Kconfig        |    1 -
 arch/hexagon/Kconfig      |    1 -
 arch/parisc/Kconfig       |    2 --
 arch/powerpc/Kconfig      |    1 -
 arch/s390/Kconfig         |    2 +-
 arch/sh/Kconfig           |    2 +-
 arch/um/Kconfig.common    |    1 -
 arch/x86/Kconfig          |    1 -
 include/asm-generic/bug.h |   29 -----------------------------
 init/Kconfig              |   10 ----------
 lib/Kconfig.debug         |    2 +-
 14 files changed, 3 insertions(+), 52 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index a7fc5ea..ea4a146 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -265,7 +265,6 @@ config PHYS_OFFSET
 
 config GENERIC_BUG
 	def_bool y
-	depends on BUG
 
 source "init/Kconfig"
 
diff --git a/arch/avr32/Kconfig b/arch/avr32/Kconfig
index bdc3558..7c9005a 100644
--- a/arch/avr32/Kconfig
+++ b/arch/avr32/Kconfig
@@ -55,7 +55,6 @@ config GENERIC_CALIBRATE_DELAY
 
 config GENERIC_BUG
 	def_bool y
-	depends on BUG
 
 source "init/Kconfig"
 
diff --git a/arch/blackfin/Kconfig b/arch/blackfin/Kconfig
index a117652..637dc42 100644
--- a/arch/blackfin/Kconfig
+++ b/arch/blackfin/Kconfig
@@ -47,7 +47,6 @@ config GENERIC_CSUM
 
 config GENERIC_BUG
 	def_bool y
-	depends on BUG
 
 config ZONE_DMA
 	def_bool y
diff --git a/arch/h8300/Kconfig b/arch/h8300/Kconfig
index 303e4f9..88848da 100644
--- a/arch/h8300/Kconfig
+++ b/arch/h8300/Kconfig
@@ -56,7 +56,6 @@ config GENERIC_CALIBRATE_DELAY
 
 config GENERIC_BUG
         bool
-        depends on BUG
 
 config TIME_LOW_RES
 	bool
diff --git a/arch/hexagon/Kconfig b/arch/hexagon/Kconfig
index 33a9792..f50cc8f 100644
--- a/arch/hexagon/Kconfig
+++ b/arch/hexagon/Kconfig
@@ -84,7 +84,6 @@ config STACKTRACE_SUPPORT
 
 config GENERIC_BUG
 	def_bool y
-	depends on BUG
 
 menu "Machine selection"
 
diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig
index 6507dab..5de1f8c 100644
--- a/arch/parisc/Kconfig
+++ b/arch/parisc/Kconfig
@@ -10,7 +10,6 @@ config PARISC
 	select RTC_CLASS
 	select RTC_DRV_GENERIC
 	select INIT_ALL_POSSIBLE
-	select BUG
 	select HAVE_PERF_EVENTS
 	select GENERIC_ATOMIC64 if !64BIT
 	select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
@@ -62,7 +61,6 @@ config ARCH_HAS_ILOG2_U64
 config GENERIC_BUG
 	bool
 	default y
-	depends on BUG
 
 config GENERIC_HWEIGHT
 	bool
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index c33e3ad..34f4ca9 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -187,7 +187,6 @@ config AUDIT_ARCH
 config GENERIC_BUG
 	bool
 	default y
-	depends on BUG
 
 config SYS_SUPPORTS_APM_EMULATION
 	default y if PMAC_APM_EMU
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index da183c5..5d7b3db 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -29,7 +29,7 @@ config GENERIC_HWEIGHT
 	def_bool y
 
 config GENERIC_BUG
-	def_bool y if BUG
+	def_bool y
 
 config GENERIC_BUG_RELATIVE_POINTERS
 	def_bool y
diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
index 8c868cf..d555e7f 100644
--- a/arch/sh/Kconfig
+++ b/arch/sh/Kconfig
@@ -84,7 +84,7 @@ config RWSEM_XCHGADD_ALGORITHM
 
 config GENERIC_BUG
 	def_bool y
-	depends on BUG && SUPERH32
+	depends on SUPERH32
 
 config GENERIC_CSUM
 	def_bool y
diff --git a/arch/um/Kconfig.common b/arch/um/Kconfig.common
index bceee66..7aae42a 100644
--- a/arch/um/Kconfig.common
+++ b/arch/um/Kconfig.common
@@ -53,7 +53,6 @@ config GENERIC_CALIBRATE_DELAY
 config GENERIC_BUG
 	bool
 	default y
-	depends on BUG
 
 config HZ
 	int
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 723e42e..a36e1b4 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -166,7 +166,6 @@ config GENERIC_ISA_DMA
 
 config GENERIC_BUG
 	def_bool y
-	depends on BUG
 	select GENERIC_BUG_RELATIVE_POINTERS if X86_64
 
 config GENERIC_BUG_RELATIVE_POINTERS
diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
index 7d10f96..5d50903 100644
--- a/include/asm-generic/bug.h
+++ b/include/asm-generic/bug.h
@@ -12,8 +12,6 @@
 #ifndef __ASSEMBLY__
 #include <linux/kernel.h>
 
-#ifdef CONFIG_BUG
-
 #ifdef CONFIG_GENERIC_BUG
 struct bug_entry {
 #ifndef CONFIG_GENERIC_BUG_RELATIVE_POINTERS
@@ -106,33 +104,6 @@ extern void warn_slowpath_null(const char *file, const int line);
 	unlikely(__ret_warn_on);					\
 })
 
-#else /* !CONFIG_BUG */
-#ifndef HAVE_ARCH_BUG
-#define BUG() do {} while(0)
-#endif
-
-#ifndef HAVE_ARCH_BUG_ON
-#define BUG_ON(condition) do { if (condition) ; } while(0)
-#endif
-
-#ifndef HAVE_ARCH_WARN_ON
-#define WARN_ON(condition) ({						\
-	int __ret_warn_on = !!(condition);				\
-	unlikely(__ret_warn_on);					\
-})
-#endif
-
-#ifndef WARN
-#define WARN(condition, format...) ({					\
-	int __ret_warn_on = !!(condition);				\
-	unlikely(__ret_warn_on);					\
-})
-#endif
-
-#define WARN_TAINT(condition, taint, format...) WARN_ON(condition)
-
-#endif
-
 #define WARN_ON_ONCE(condition)	({				\
 	static bool __section(.data.unlikely) __warned;		\
 	int __ret_warn_once = !!(condition);			\
diff --git a/init/Kconfig b/init/Kconfig
index 7fb26a6..bc1dd49 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1360,16 +1360,6 @@ config PRINTK
 	  very difficult to diagnose system problems, saying N here is
 	  strongly discouraged.
 
-config BUG
-	bool "BUG() support" if EXPERT
-	default y
-	help
-          Disabling this option eliminates support for BUG and WARN, reducing
-          the size of your kernel image and potentially quietly ignoring
-          numerous fatal conditions. You should only consider disabling this
-          option for embedded systems with no facilities for reporting errors.
-          Just say Y.
-
 config ELF_CORE
 	depends on COREDUMP
 	default y
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 566cf2b..54b3251 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -700,7 +700,7 @@ config HAVE_DEBUG_BUGVERBOSE
 
 config DEBUG_BUGVERBOSE
 	bool "Verbose BUG() reporting (adds 70K)" if DEBUG_KERNEL && EXPERT
-	depends on BUG && (GENERIC_BUG || HAVE_DEBUG_BUGVERBOSE)
+	depends on GENERIC_BUG || HAVE_DEBUG_BUGVERBOSE
 	default y
 	help
 	  Say Y here to make BUG() panics output the file name and line number
-- 
1.7.7.6

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Geert Uytterhoeven]

On Thu, May 23, 2013 at 9:57 AM, Chen Gang <gang.chen@asianux.com> wrote:
> The crazy user can unset 'CONFIG_BUG' in menuconfig: "> General setup >
> Configure standard kernel features (expert users) > BUG() Support".
>
> But in fact, we always need it, and quite a few of architectures have

Sorry, but we don't. I think you don't get the meaning of the BUG config symbol
(see below).

> already implemented it (e.g. alpha, arc, arm, avr32, blackfin, cris,
> frv, ia64, m68k, mips, mn10300, parisc, powerpc, s390, sh, sparc, x86).

What do you mean by "already implemented it"? E.g. on m68k, I can disable
or enable CONFIG_BUG. Both work.

> And kernel also already has prepared a default effective implementation
> for the architectures which is unwilling to implement it by themselves
> (e.g. arm64, c6x, h8300, hexagon, m32r, metag, microblaze, openrisc,
> score, tile, um, unicore32, xtensa).

This is not about providing an implementation or not...

> -config BUG
> -       bool "BUG() support" if EXPERT
> -       default y
> -       help
> -          Disabling this option eliminates support for BUG and WARN, reducing
> -          the size of your kernel image and potentially quietly ignoring
> -          numerous fatal conditions. You should only consider disabling this
> -          option for embedded systems with no facilities for reporting errors.
> -          Just say Y.

... It's about reducing memory size on devices where you can't show bug or
warning messages.

> So need get rid of 'CONFIG_BUG', and let it always enabled everywhere.

So please keep it.

Thanks!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Geert Uytterhoeven]

On Thu, May 23, 2013 at 9:57 AM, Chen Gang <gang.chen@asianux.com> wrote:
> The crazy user can unset 'CONFIG_BUG' in menuconfig: "> General setup >
> Configure standard kernel features (expert users) > BUG() Support".
>
> But in fact, we always need it, and quite a few of architectures have

Sorry, but we don't. I think you don't get the meaning of the BUG config symbol
(see below).

> already implemented it (e.g. alpha, arc, arm, avr32, blackfin, cris,
> frv, ia64, m68k, mips, mn10300, parisc, powerpc, s390, sh, sparc, x86).

What do you mean by "already implemented it"? E.g. on m68k, I can disable
or enable CONFIG_BUG. Both work.

> And kernel also already has prepared a default effective implementation
> for the architectures which is unwilling to implement it by themselves
> (e.g. arm64, c6x, h8300, hexagon, m32r, metag, microblaze, openrisc,
> score, tile, um, unicore32, xtensa).

This is not about providing an implementation or not...

> -config BUG
> -       bool "BUG() support" if EXPERT
> -       default y
> -       help
> -          Disabling this option eliminates support for BUG and WARN, reducing
> -          the size of your kernel image and potentially quietly ignoring
> -          numerous fatal conditions. You should only consider disabling this
> -          option for embedded systems with no facilities for reporting errors.
> -          Just say Y.

... It's about reducing memory size on devices where you can't show bug or
warning messages.

> So need get rid of 'CONFIG_BUG', and let it always enabled everywhere.

So please keep it.

Thanks!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Geert Uytterhoeven]

On Thu, May 23, 2013 at 9:57 AM, Chen Gang <gang.chen@asianux.com> wrote:
> The crazy user can unset 'CONFIG_BUG' in menuconfig: "> General setup >
> Configure standard kernel features (expert users) > BUG() Support".
>
> But in fact, we always need it, and quite a few of architectures have

Sorry, but we don't. I think you don't get the meaning of the BUG config symbol
(see below).

> already implemented it (e.g. alpha, arc, arm, avr32, blackfin, cris,
> frv, ia64, m68k, mips, mn10300, parisc, powerpc, s390, sh, sparc, x86).

What do you mean by "already implemented it"? E.g. on m68k, I can disable
or enable CONFIG_BUG. Both work.

> And kernel also already has prepared a default effective implementation
> for the architectures which is unwilling to implement it by themselves
> (e.g. arm64, c6x, h8300, hexagon, m32r, metag, microblaze, openrisc,
> score, tile, um, unicore32, xtensa).

This is not about providing an implementation or not...

> -config BUG
> -       bool "BUG() support" if EXPERT
> -       default y
> -       help
> -          Disabling this option eliminates support for BUG and WARN, reducing
> -          the size of your kernel image and potentially quietly ignoring
> -          numerous fatal conditions. You should only consider disabling this
> -          option for embedded systems with no facilities for reporting errors.
> -          Just say Y.

... It's about reducing memory size on devices where you can't show bug or
warning messages.

> So need get rid of 'CONFIG_BUG', and let it always enabled everywhere.

So please keep it.

Thanks!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Geert Uytterhoeven]

On Thu, May 23, 2013 at 9:57 AM, Chen Gang <gang.chen@asianux.com> wrote:
> The crazy user can unset 'CONFIG_BUG' in menuconfig: "> General setup >
> Configure standard kernel features (expert users) > BUG() Support".
>
> But in fact, we always need it, and quite a few of architectures have

Sorry, but we don't. I think you don't get the meaning of the BUG config symbol
(see below).

> already implemented it (e.g. alpha, arc, arm, avr32, blackfin, cris,
> frv, ia64, m68k, mips, mn10300, parisc, powerpc, s390, sh, sparc, x86).

What do you mean by "already implemented it"? E.g. on m68k, I can disable
or enable CONFIG_BUG. Both work.

> And kernel also already has prepared a default effective implementation
> for the architectures which is unwilling to implement it by themselves
> (e.g. arm64, c6x, h8300, hexagon, m32r, metag, microblaze, openrisc,
> score, tile, um, unicore32, xtensa).

This is not about providing an implementation or not...

> -config BUG
> -       bool "BUG() support" if EXPERT
> -       default y
> -       help
> -          Disabling this option eliminates support for BUG and WARN, reducing
> -          the size of your kernel image and potentially quietly ignoring
> -          numerous fatal conditions. You should only consider disabling this
> -          option for embedded systems with no facilities for reporting errors.
> -          Just say Y.

... It's about reducing memory size on devices where you can't show bug or
warning messages.

> So need get rid of 'CONFIG_BUG', and let it always enabled everywhere.

So please keep it.

Thanks!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Arnd Bergmann]

On Thursday 23 May 2013, Geert Uytterhoeven wrote:
> > -config BUG
> > -       bool "BUG() support" if EXPERT
> > -       default y
> > -       help
> > -          Disabling this option eliminates support for BUG and WARN, reducing
> > -          the size of your kernel image and potentially quietly ignoring
> > -          numerous fatal conditions. You should only consider disabling this
> > -          option for embedded systems with no facilities for reporting errors.
> > -          Just say Y.
> 
> ... It's about reducing memory size on devices where you can't show bug or
> warning messages.
> 
> > So need get rid of 'CONFIG_BUG', and let it always enabled everywhere.
> 
> So please keep it.

Agreed. The one annoying property of disabling BUG() support is that it causes
a large number of build warnings since the compiler now has to assume that a lot
of code is reachable when it is normally annotate as unreachable.

When I do "randconfig" tests, I always turn on CONFIG_BUG because of this.

	Arnd

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Arnd Bergmann]

On Thursday 23 May 2013, Geert Uytterhoeven wrote:
> > -config BUG
> > -       bool "BUG() support" if EXPERT
> > -       default y
> > -       help
> > -          Disabling this option eliminates support for BUG and WARN, reducing
> > -          the size of your kernel image and potentially quietly ignoring
> > -          numerous fatal conditions. You should only consider disabling this
> > -          option for embedded systems with no facilities for reporting errors.
> > -          Just say Y.
> 
> ... It's about reducing memory size on devices where you can't show bug or
> warning messages.
> 
> > So need get rid of 'CONFIG_BUG', and let it always enabled everywhere.
> 
> So please keep it.

Agreed. The one annoying property of disabling BUG() support is that it causes
a large number of build warnings since the compiler now has to assume that a lot
of code is reachable when it is normally annotate as unreachable.

When I do "randconfig" tests, I always turn on CONFIG_BUG because of this.

	Arnd

[PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Arnd Bergmann]

On Thursday 23 May 2013, Geert Uytterhoeven wrote:
> > -config BUG
> > -       bool "BUG() support" if EXPERT
> > -       default y
> > -       help
> > -          Disabling this option eliminates support for BUG and WARN, reducing
> > -          the size of your kernel image and potentially quietly ignoring
> > -          numerous fatal conditions. You should only consider disabling this
> > -          option for embedded systems with no facilities for reporting errors.
> > -          Just say Y.
> 
> ... It's about reducing memory size on devices where you can't show bug or
> warning messages.
> 
> > So need get rid of 'CONFIG_BUG', and let it always enabled everywhere.
> 
> So please keep it.

Agreed. The one annoying property of disabling BUG() support is that it causes
a large number of build warnings since the compiler now has to assume that a lot
of code is reachable when it is normally annotate as unreachable.

When I do "randconfig" tests, I always turn on CONFIG_BUG because of this.

	Arnd

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Arnd Bergmann]

On Thursday 23 May 2013, Geert Uytterhoeven wrote:
> > -config BUG
> > -       bool "BUG() support" if EXPERT
> > -       default y
> > -       help
> > -          Disabling this option eliminates support for BUG and WARN, reducing
> > -          the size of your kernel image and potentially quietly ignoring
> > -          numerous fatal conditions. You should only consider disabling this
> > -          option for embedded systems with no facilities for reporting errors.
> > -          Just say Y.
> 
> ... It's about reducing memory size on devices where you can't show bug or
> warning messages.
> 
> > So need get rid of 'CONFIG_BUG', and let it always enabled everywhere.
> 
> So please keep it.

Agreed. The one annoying property of disabling BUG() support is that it causes
a large number of build warnings since the compiler now has to assume that a lot
of code is reachable when it is normally annotate as unreachable.

When I do "randconfig" tests, I always turn on CONFIG_BUG because of this.

	Arnd

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Russell King - ARM Linux]

On Thu, May 23, 2013 at 10:40:29AM +0200, Geert Uytterhoeven wrote:
> On Thu, May 23, 2013 at 9:57 AM, Chen Gang <gang.chen-bOixZGp5f+dBDgjK7y7TUQ@public.gmane.org> wrote:
> > -config BUG
> > -       bool "BUG() support" if EXPERT
> > -       default y
> > -       help
> > -          Disabling this option eliminates support for BUG and WARN, reducing
> > -          the size of your kernel image and potentially quietly ignoring
> > -          numerous fatal conditions. You should only consider disabling this
> > -          option for embedded systems with no facilities for reporting errors.
> > -          Just say Y.
> 
> ... It's about reducing memory size on devices where you can't show bug or
> warning messages.

And turning off CONFIG_BUG causes lots of warning messages at compile time
about functions which are returning nothing which shouldn't.

The problem is: trying to fix that _will_ mean the result is a larger
kernel than if you just do the usual arch-implemented thing of placing
an defined faulting instruction at the BUG() site - which defeats the
purpose of turning off CONFIG_BUG.

Therefore, it's better that CONFIG_BUG always be y and we stop kidding
ourselves that it's possible to turn this off and safely save space.

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Russell King - ARM Linux]

On Thu, May 23, 2013 at 10:40:29AM +0200, Geert Uytterhoeven wrote:
> On Thu, May 23, 2013 at 9:57 AM, Chen Gang <gang.chen-bOixZGp5f+dBDgjK7y7TUQ@public.gmane.org> wrote:
> > -config BUG
> > -       bool "BUG() support" if EXPERT
> > -       default y
> > -       help
> > -          Disabling this option eliminates support for BUG and WARN, reducing
> > -          the size of your kernel image and potentially quietly ignoring
> > -          numerous fatal conditions. You should only consider disabling this
> > -          option for embedded systems with no facilities for reporting errors.
> > -          Just say Y.
> 
> ... It's about reducing memory size on devices where you can't show bug or
> warning messages.

And turning off CONFIG_BUG causes lots of warning messages at compile time
about functions which are returning nothing which shouldn't.

The problem is: trying to fix that _will_ mean the result is a larger
kernel than if you just do the usual arch-implemented thing of placing
an defined faulting instruction at the BUG() site - which defeats the
purpose of turning off CONFIG_BUG.

Therefore, it's better that CONFIG_BUG always be y and we stop kidding
ourselves that it's possible to turn this off and safely save space.

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Russell King - ARM Linux]

On Thu, May 23, 2013 at 10:40:29AM +0200, Geert Uytterhoeven wrote:
> On Thu, May 23, 2013 at 9:57 AM, Chen Gang <gang.chen@asianux.com> wrote:
> > -config BUG
> > -       bool "BUG() support" if EXPERT
> > -       default y
> > -       help
> > -          Disabling this option eliminates support for BUG and WARN, reducing
> > -          the size of your kernel image and potentially quietly ignoring
> > -          numerous fatal conditions. You should only consider disabling this
> > -          option for embedded systems with no facilities for reporting errors.
> > -          Just say Y.
> 
> ... It's about reducing memory size on devices where you can't show bug or
> warning messages.

And turning off CONFIG_BUG causes lots of warning messages at compile time
about functions which are returning nothing which shouldn't.

The problem is: trying to fix that _will_ mean the result is a larger
kernel than if you just do the usual arch-implemented thing of placing
an defined faulting instruction at the BUG() site - which defeats the
purpose of turning off CONFIG_BUG.

Therefore, it's better that CONFIG_BUG always be y and we stop kidding
ourselves that it's possible to turn this off and safely save space.

[PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Russell King - ARM Linux]

On Thu, May 23, 2013 at 10:40:29AM +0200, Geert Uytterhoeven wrote:
> On Thu, May 23, 2013 at 9:57 AM, Chen Gang <gang.chen@asianux.com> wrote:
> > -config BUG
> > -       bool "BUG() support" if EXPERT
> > -       default y
> > -       help
> > -          Disabling this option eliminates support for BUG and WARN, reducing
> > -          the size of your kernel image and potentially quietly ignoring
> > -          numerous fatal conditions. You should only consider disabling this
> > -          option for embedded systems with no facilities for reporting errors.
> > -          Just say Y.
> 
> ... It's about reducing memory size on devices where you can't show bug or
> warning messages.

And turning off CONFIG_BUG causes lots of warning messages at compile time
about functions which are returning nothing which shouldn't.

The problem is: trying to fix that _will_ mean the result is a larger
kernel than if you just do the usual arch-implemented thing of placing
an defined faulting instruction at the BUG() site - which defeats the
purpose of turning off CONFIG_BUG.

Therefore, it's better that CONFIG_BUG always be y and we stop kidding
ourselves that it's possible to turn this off and safely save space.

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Russell King - ARM Linux]

On Thu, May 23, 2013 at 10:40:29AM +0200, Geert Uytterhoeven wrote:
> On Thu, May 23, 2013 at 9:57 AM, Chen Gang <gang.chen@asianux.com> wrote:
> > -config BUG
> > -       bool "BUG() support" if EXPERT
> > -       default y
> > -       help
> > -          Disabling this option eliminates support for BUG and WARN, reducing
> > -          the size of your kernel image and potentially quietly ignoring
> > -          numerous fatal conditions. You should only consider disabling this
> > -          option for embedded systems with no facilities for reporting errors.
> > -          Just say Y.
> 
> ... It's about reducing memory size on devices where you can't show bug or
> warning messages.

And turning off CONFIG_BUG causes lots of warning messages at compile time
about functions which are returning nothing which shouldn't.

The problem is: trying to fix that _will_ mean the result is a larger
kernel than if you just do the usual arch-implemented thing of placing
an defined faulting instruction at the BUG() site - which defeats the
purpose of turning off CONFIG_BUG.

Therefore, it's better that CONFIG_BUG always be y and we stop kidding
ourselves that it's possible to turn this off and safely save space.

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Geert Uytterhoeven]

On Thu, May 23, 2013 at 11:05 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Thu, May 23, 2013 at 10:40:29AM +0200, Geert Uytterhoeven wrote:
>> On Thu, May 23, 2013 at 9:57 AM, Chen Gang <gang.chen@asianux.com> wrote:
>> > -config BUG
>> > -       bool "BUG() support" if EXPERT
>> > -       default y
>> > -       help
>> > -          Disabling this option eliminates support for BUG and WARN, reducing
>> > -          the size of your kernel image and potentially quietly ignoring
>> > -          numerous fatal conditions. You should only consider disabling this
>> > -          option for embedded systems with no facilities for reporting errors.
>> > -          Just say Y.
>>
>> ... It's about reducing memory size on devices where you can't show bug or
>> warning messages.
>
> And turning off CONFIG_BUG causes lots of warning messages at compile time
> about functions which are returning nothing which shouldn't.
>
> The problem is: trying to fix that _will_ mean the result is a larger
> kernel than if you just do the usual arch-implemented thing of placing
> an defined faulting instruction at the BUG() site - which defeats the
> purpose of turning off CONFIG_BUG.

Is __builtin_unreachable() working well these days?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Geert Uytterhoeven]

On Thu, May 23, 2013 at 11:05 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Thu, May 23, 2013 at 10:40:29AM +0200, Geert Uytterhoeven wrote:
>> On Thu, May 23, 2013 at 9:57 AM, Chen Gang <gang.chen@asianux.com> wrote:
>> > -config BUG
>> > -       bool "BUG() support" if EXPERT
>> > -       default y
>> > -       help
>> > -          Disabling this option eliminates support for BUG and WARN, reducing
>> > -          the size of your kernel image and potentially quietly ignoring
>> > -          numerous fatal conditions. You should only consider disabling this
>> > -          option for embedded systems with no facilities for reporting errors.
>> > -          Just say Y.
>>
>> ... It's about reducing memory size on devices where you can't show bug or
>> warning messages.
>
> And turning off CONFIG_BUG causes lots of warning messages at compile time
> about functions which are returning nothing which shouldn't.
>
> The problem is: trying to fix that _will_ mean the result is a larger
> kernel than if you just do the usual arch-implemented thing of placing
> an defined faulting instruction at the BUG() site - which defeats the
> purpose of turning off CONFIG_BUG.

Is __builtin_unreachable() working well these days?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Geert Uytterhoeven]

On Thu, May 23, 2013 at 11:05 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Thu, May 23, 2013 at 10:40:29AM +0200, Geert Uytterhoeven wrote:
>> On Thu, May 23, 2013 at 9:57 AM, Chen Gang <gang.chen@asianux.com> wrote:
>> > -config BUG
>> > -       bool "BUG() support" if EXPERT
>> > -       default y
>> > -       help
>> > -          Disabling this option eliminates support for BUG and WARN, reducing
>> > -          the size of your kernel image and potentially quietly ignoring
>> > -          numerous fatal conditions. You should only consider disabling this
>> > -          option for embedded systems with no facilities for reporting errors.
>> > -          Just say Y.
>>
>> ... It's about reducing memory size on devices where you can't show bug or
>> warning messages.
>
> And turning off CONFIG_BUG causes lots of warning messages at compile time
> about functions which are returning nothing which shouldn't.
>
> The problem is: trying to fix that _will_ mean the result is a larger
> kernel than if you just do the usual arch-implemented thing of placing
> an defined faulting instruction at the BUG() site - which defeats the
> purpose of turning off CONFIG_BUG.

Is __builtin_unreachable() working well these days?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Geert Uytterhoeven]

On Thu, May 23, 2013 at 11:05 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Thu, May 23, 2013 at 10:40:29AM +0200, Geert Uytterhoeven wrote:
>> On Thu, May 23, 2013 at 9:57 AM, Chen Gang <gang.chen@asianux.com> wrote:
>> > -config BUG
>> > -       bool "BUG() support" if EXPERT
>> > -       default y
>> > -       help
>> > -          Disabling this option eliminates support for BUG and WARN, reducing
>> > -          the size of your kernel image and potentially quietly ignoring
>> > -          numerous fatal conditions. You should only consider disabling this
>> > -          option for embedded systems with no facilities for reporting errors.
>> > -          Just say Y.
>>
>> ... It's about reducing memory size on devices where you can't show bug or
>> warning messages.
>
> And turning off CONFIG_BUG causes lots of warning messages at compile time
> about functions which are returning nothing which shouldn't.
>
> The problem is: trying to fix that _will_ mean the result is a larger
> kernel than if you just do the usual arch-implemented thing of placing
> an defined faulting instruction at the BUG() site - which defeats the
> purpose of turning off CONFIG_BUG.

Is __builtin_unreachable() working well these days?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Arnd Bergmann]

On Thursday 23 May 2013, Geert Uytterhoeven wrote:
> > The problem is: trying to fix that will mean the result is a larger
> > kernel than if you just do the usual arch-implemented thing of placing
> > an defined faulting instruction at the BUG() site - which defeats the
> > purpose of turning off CONFIG_BUG.
> 
> Is __builtin_unreachable() working well these days?
> 

Hmm, I just tried the trivial patch below, which seemed to do the right thing.
Needs a little more investigation, but that might actually be the correct
solution. I thought that at some point __builtin_unreachable() was the same
as "do {} while (1)", but this is not the case with the gcc I was using --
it just tells gcc that we don't expect to ever get here.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>

diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
index 7d10f96..9afff7d 100644
--- a/include/asm-generic/bug.h
+++ b/include/asm-generic/bug.h
@@ -108,11 +108,11 @@ extern void warn_slowpath_null(const char *file, const int line);
 
 #else /* !CONFIG_BUG */
 #ifndef HAVE_ARCH_BUG
-#define BUG() do {} while(0)
+#define BUG() __builtin_unreachable ()
 #endif
 
 #ifndef HAVE_ARCH_BUG_ON
-#define BUG_ON(condition) do { if (condition) ; } while(0)
+#define BUG_ON(condition) do { if (condition) __builtin_unreachable(); } while(0)
 #endif
 
 #ifndef HAVE_ARCH_WARN_ON

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Arnd Bergmann]

On Thursday 23 May 2013, Geert Uytterhoeven wrote:
> > The problem is: trying to fix that will mean the result is a larger
> > kernel than if you just do the usual arch-implemented thing of placing
> > an defined faulting instruction at the BUG() site - which defeats the
> > purpose of turning off CONFIG_BUG.
> 
> Is __builtin_unreachable() working well these days?
> 

Hmm, I just tried the trivial patch below, which seemed to do the right thing.
Needs a little more investigation, but that might actually be the correct
solution. I thought that at some point __builtin_unreachable() was the same
as "do {} while (1)", but this is not the case with the gcc I was using --
it just tells gcc that we don't expect to ever get here.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>

diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
index 7d10f96..9afff7d 100644
--- a/include/asm-generic/bug.h
+++ b/include/asm-generic/bug.h
@@ -108,11 +108,11 @@ extern void warn_slowpath_null(const char *file, const int line);
 
 #else /* !CONFIG_BUG */
 #ifndef HAVE_ARCH_BUG
-#define BUG() do {} while(0)
+#define BUG() __builtin_unreachable ()
 #endif
 
 #ifndef HAVE_ARCH_BUG_ON
-#define BUG_ON(condition) do { if (condition) ; } while(0)
+#define BUG_ON(condition) do { if (condition) __builtin_unreachable(); } while(0)
 #endif
 
 #ifndef HAVE_ARCH_WARN_ON

[PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Arnd Bergmann]

On Thursday 23 May 2013, Geert Uytterhoeven wrote:
> > The problem is: trying to fix that will mean the result is a larger
> > kernel than if you just do the usual arch-implemented thing of placing
> > an defined faulting instruction at the BUG() site - which defeats the
> > purpose of turning off CONFIG_BUG.
> 
> Is __builtin_unreachable() working well these days?
> 

Hmm, I just tried the trivial patch below, which seemed to do the right thing.
Needs a little more investigation, but that might actually be the correct
solution. I thought that at some point __builtin_unreachable() was the same
as "do {} while (1)", but this is not the case with the gcc I was using --
it just tells gcc that we don't expect to ever get here.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>

diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
index 7d10f96..9afff7d 100644
--- a/include/asm-generic/bug.h
+++ b/include/asm-generic/bug.h
@@ -108,11 +108,11 @@ extern void warn_slowpath_null(const char *file, const int line);
 
 #else /* !CONFIG_BUG */
 #ifndef HAVE_ARCH_BUG
-#define BUG() do {} while(0)
+#define BUG() __builtin_unreachable ()
 #endif
 
 #ifndef HAVE_ARCH_BUG_ON
-#define BUG_ON(condition) do { if (condition) ; } while(0)
+#define BUG_ON(condition) do { if (condition) __builtin_unreachable(); } while(0)
 #endif
 
 #ifndef HAVE_ARCH_WARN_ON

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Arnd Bergmann]

On Thursday 23 May 2013, Geert Uytterhoeven wrote:
> > The problem is: trying to fix that will mean the result is a larger
> > kernel than if you just do the usual arch-implemented thing of placing
> > an defined faulting instruction at the BUG() site - which defeats the
> > purpose of turning off CONFIG_BUG.
> 
> Is __builtin_unreachable() working well these days?
> 

Hmm, I just tried the trivial patch below, which seemed to do the right thing.
Needs a little more investigation, but that might actually be the correct
solution. I thought that at some point __builtin_unreachable() was the same
as "do {} while (1)", but this is not the case with the gcc I was using --
it just tells gcc that we don't expect to ever get here.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>

diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
index 7d10f96..9afff7d 100644
--- a/include/asm-generic/bug.h
+++ b/include/asm-generic/bug.h
@@ -108,11 +108,11 @@ extern void warn_slowpath_null(const char *file, const int line);
 
 #else /* !CONFIG_BUG */
 #ifndef HAVE_ARCH_BUG
-#define BUG() do {} while(0)
+#define BUG() __builtin_unreachable ()
 #endif
 
 #ifndef HAVE_ARCH_BUG_ON
-#define BUG_ON(condition) do { if (condition) ; } while(0)
+#define BUG_ON(condition) do { if (condition) __builtin_unreachable(); } while(0)
 #endif
 
 #ifndef HAVE_ARCH_WARN_ON

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Russell King - ARM Linux]

On Thu, May 23, 2013 at 11:39:37AM +0200, Arnd Bergmann wrote:
> On Thursday 23 May 2013, Geert Uytterhoeven wrote:
> > > The problem is: trying to fix that will mean the result is a larger
> > > kernel than if you just do the usual arch-implemented thing of placing
> > > an defined faulting instruction at the BUG() site - which defeats the
> > > purpose of turning off CONFIG_BUG.
> > 
> > Is __builtin_unreachable() working well these days?
> > 
> 
> Hmm, I just tried the trivial patch below, which seemed to do the right thing.
> Needs a little more investigation, but that might actually be the correct
> solution. I thought that at some point __builtin_unreachable() was the same
> as "do {} while (1)", but this is not the case with the gcc I was using --
> it just tells gcc that we don't expect to ever get here.

All this is doing is hiding the warning, nothing more.

What the compiler does is this:

	beq	1f
	... some asm code ...
	__builtin_reachable() point
	maybe a literal table
1:	... some asm code doing some other part of the function ...

and what will happen is that the first block of asm will fall through the
(possibly present) literal table into the following asm code.  So, as
specified in the gcc manual, if you ever hit a __builtin_unreachable()
point, your program is undefined (as in, the behaviour of it can no longer
be known.)

We can't make that guarantee with BUG() - because sometimes they do fire
and sometimes in the most unlikely scenarios, particularly if you're not
looking, or at the most inconvenient time.

So, if you want to use this, then you should update the CONFIG_BUG text
to include a warning to this effect:

     Warning: if CONFIG_BUG is turned off, and control flow reaches
     a BUG(), the system behaviour will be undefined.

so that people can make an informed choice about this, because at the
moment:

          Disabling this option eliminates support for BUG and WARN, reducing
          the size of your kernel image and potentially quietly ignoring
          numerous fatal conditions. You should only consider disabling this
          option for embedded systems with no facilities for reporting errors.
          Just say Y.

will become completely misleading.  Turning this option off will _not_
result in "quietly ignoring numerous fatal conditions".

And I come back to one of my previous arguments - is it not better to
panic() if we hit one of these conditions so that the system can try to
do a panic-reboot rather than continue blindly into the unknown?

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Russell King - ARM Linux]

On Thu, May 23, 2013 at 11:39:37AM +0200, Arnd Bergmann wrote:
> On Thursday 23 May 2013, Geert Uytterhoeven wrote:
> > > The problem is: trying to fix that will mean the result is a larger
> > > kernel than if you just do the usual arch-implemented thing of placing
> > > an defined faulting instruction at the BUG() site - which defeats the
> > > purpose of turning off CONFIG_BUG.
> > 
> > Is __builtin_unreachable() working well these days?
> > 
> 
> Hmm, I just tried the trivial patch below, which seemed to do the right thing.
> Needs a little more investigation, but that might actually be the correct
> solution. I thought that at some point __builtin_unreachable() was the same
> as "do {} while (1)", but this is not the case with the gcc I was using --
> it just tells gcc that we don't expect to ever get here.

All this is doing is hiding the warning, nothing more.

What the compiler does is this:

	beq	1f
	... some asm code ...
	__builtin_reachable() point
	maybe a literal table
1:	... some asm code doing some other part of the function ...

and what will happen is that the first block of asm will fall through the
(possibly present) literal table into the following asm code.  So, as
specified in the gcc manual, if you ever hit a __builtin_unreachable()
point, your program is undefined (as in, the behaviour of it can no longer
be known.)

We can't make that guarantee with BUG() - because sometimes they do fire
and sometimes in the most unlikely scenarios, particularly if you're not
looking, or at the most inconvenient time.

So, if you want to use this, then you should update the CONFIG_BUG text
to include a warning to this effect:

     Warning: if CONFIG_BUG is turned off, and control flow reaches
     a BUG(), the system behaviour will be undefined.

so that people can make an informed choice about this, because at the
moment:

          Disabling this option eliminates support for BUG and WARN, reducing
          the size of your kernel image and potentially quietly ignoring
          numerous fatal conditions. You should only consider disabling this
          option for embedded systems with no facilities for reporting errors.
          Just say Y.

will become completely misleading.  Turning this option off will _not_
result in "quietly ignoring numerous fatal conditions".

And I come back to one of my previous arguments - is it not better to
panic() if we hit one of these conditions so that the system can try to
do a panic-reboot rather than continue blindly into the unknown?

[PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Russell King - ARM Linux]

On Thu, May 23, 2013 at 11:39:37AM +0200, Arnd Bergmann wrote:
> On Thursday 23 May 2013, Geert Uytterhoeven wrote:
> > > The problem is: trying to fix that will mean the result is a larger
> > > kernel than if you just do the usual arch-implemented thing of placing
> > > an defined faulting instruction at the BUG() site - which defeats the
> > > purpose of turning off CONFIG_BUG.
> > 
> > Is __builtin_unreachable() working well these days?
> > 
> 
> Hmm, I just tried the trivial patch below, which seemed to do the right thing.
> Needs a little more investigation, but that might actually be the correct
> solution. I thought that at some point __builtin_unreachable() was the same
> as "do {} while (1)", but this is not the case with the gcc I was using --
> it just tells gcc that we don't expect to ever get here.

All this is doing is hiding the warning, nothing more.

What the compiler does is this:

	beq	1f
	... some asm code ...
	__builtin_reachable() point
	maybe a literal table
1:	... some asm code doing some other part of the function ...

and what will happen is that the first block of asm will fall through the
(possibly present) literal table into the following asm code.  So, as
specified in the gcc manual, if you ever hit a __builtin_unreachable()
point, your program is undefined (as in, the behaviour of it can no longer
be known.)

We can't make that guarantee with BUG() - because sometimes they do fire
and sometimes in the most unlikely scenarios, particularly if you're not
looking, or at the most inconvenient time.

So, if you want to use this, then you should update the CONFIG_BUG text
to include a warning to this effect:

     Warning: if CONFIG_BUG is turned off, and control flow reaches
     a BUG(), the system behaviour will be undefined.

so that people can make an informed choice about this, because at the
moment:

          Disabling this option eliminates support for BUG and WARN, reducing
          the size of your kernel image and potentially quietly ignoring
          numerous fatal conditions. You should only consider disabling this
          option for embedded systems with no facilities for reporting errors.
          Just say Y.

will become completely misleading.  Turning this option off will _not_
result in "quietly ignoring numerous fatal conditions".

And I come back to one of my previous arguments - is it not better to
panic() if we hit one of these conditions so that the system can try to
do a panic-reboot rather than continue blindly into the unknown?

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Russell King - ARM Linux]

On Thu, May 23, 2013 at 11:39:37AM +0200, Arnd Bergmann wrote:
> On Thursday 23 May 2013, Geert Uytterhoeven wrote:
> > > The problem is: trying to fix that will mean the result is a larger
> > > kernel than if you just do the usual arch-implemented thing of placing
> > > an defined faulting instruction at the BUG() site - which defeats the
> > > purpose of turning off CONFIG_BUG.
> > 
> > Is __builtin_unreachable() working well these days?
> > 
> 
> Hmm, I just tried the trivial patch below, which seemed to do the right thing.
> Needs a little more investigation, but that might actually be the correct
> solution. I thought that at some point __builtin_unreachable() was the same
> as "do {} while (1)", but this is not the case with the gcc I was using --
> it just tells gcc that we don't expect to ever get here.

All this is doing is hiding the warning, nothing more.

What the compiler does is this:

	beq	1f
	... some asm code ...
	__builtin_reachable() point
	maybe a literal table
1:	... some asm code doing some other part of the function ...

and what will happen is that the first block of asm will fall through the
(possibly present) literal table into the following asm code.  So, as
specified in the gcc manual, if you ever hit a __builtin_unreachable()
point, your program is undefined (as in, the behaviour of it can no longer
be known.)

We can't make that guarantee with BUG() - because sometimes they do fire
and sometimes in the most unlikely scenarios, particularly if you're not
looking, or at the most inconvenient time.

So, if you want to use this, then you should update the CONFIG_BUG text
to include a warning to this effect:

     Warning: if CONFIG_BUG is turned off, and control flow reaches
     a BUG(), the system behaviour will be undefined.

so that people can make an informed choice about this, because at the
moment:

          Disabling this option eliminates support for BUG and WARN, reducing
          the size of your kernel image and potentially quietly ignoring
          numerous fatal conditions. You should only consider disabling this
          option for embedded systems with no facilities for reporting errors.
          Just say Y.

will become completely misleading.  Turning this option off will _not_
result in "quietly ignoring numerous fatal conditions".

And I come back to one of my previous arguments - is it not better to
panic() if we hit one of these conditions so that the system can try to
do a panic-reboot rather than continue blindly into the unknown?

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Chen Gang]

[-- Attachment #1: Type: text/plain, Size: 1893 bytes --]

On 05/23/2013 05:12 PM, Geert Uytterhoeven wrote:
> On Thu, May 23, 2013 at 11:05 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
>> > On Thu, May 23, 2013 at 10:40:29AM +0200, Geert Uytterhoeven wrote:
>>> >> On Thu, May 23, 2013 at 9:57 AM, Chen Gang <gang.chen@asianux.com> wrote:
>>>> >> > -config BUG
>>>> >> > -       bool "BUG() support" if EXPERT
>>>> >> > -       default y
>>>> >> > -       help
>>>> >> > -          Disabling this option eliminates support for BUG and WARN, reducing
>>>> >> > -          the size of your kernel image and potentially quietly ignoring
>>>> >> > -          numerous fatal conditions. You should only consider disabling this
>>>> >> > -          option for embedded systems with no facilities for reporting errors.
>>>> >> > -          Just say Y.
>>> >>
>>> >> ... It's about reducing memory size on devices where you can't show bug or
>>> >> warning messages.
>> >
>> > And turning off CONFIG_BUG causes lots of warning messages at compile time
>> > about functions which are returning nothing which shouldn't.
>> >
>> > The problem is: trying to fix that _will_ mean the result is a larger
>> > kernel than if you just do the usual arch-implemented thing of placing
>> > an defined faulting instruction at the BUG() site - which defeats the
>> > purpose of turning off CONFIG_BUG.
> Is __builtin_unreachable() working well these days?

In fact, using __builtin_unreachable() is a standard way for
architectures to implemented their own BUG() (e.g. x86, s390, powerpc,
arm ...)

Before __builtin_unreachable(), must need an inline asm instruction
which architecture specific.

I have test using __builtin_unreachable() without an related asm
instruction before, it prints many unexpected things (please see the
attachment).

So I think, it is not suitable to use it in "asm-generic/bug.h"


Thanks.
-- 
Chen Gang

Asianux Corporation

[-- Attachment #2: test0.c --]
[-- Type: text/plain, Size: 1234 bytes --]

#include <stdio.h>
#include <sys/types.h>
#include <error.h>
#include <errno.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/stat.h>

int main()
{
	int file;
	int ret;
	char buf[0x100];

	file = open("/tmp/work.c", O_RDONLY);
	if (file == -1) {
		printf("\nopen file failed. errno = %d\n", errno);
		goto err;
	} else
		printf("\nopen file succeed.\n");

	printf("before unreachable\n");
	__builtin_unreachable();
	printf("after unreachable\n");

	if (lseek(file, 10, SEEK_END) < 0) {
		printf("\nlseek file failed. errno = %d\n", errno);
		goto err;
	}

	ret = read(file, buf, 0x100);
	if (ret < 0) {
		printf("\n1st read file failed. errno = %d, ret = %d\n", errno, ret);
		goto err;
	} else
		printf("\n1st read file succeed. errno = %d, ret = %d\n", errno, ret);

	ret = read(file, buf, 0x100);
	if (ret < 0) {
		printf("\n2nd read file failed. errno = %d, ret = %d\n", errno, ret);
		goto err;
	} else
		printf("\n2nd read file succeed. errno = %d, ret = %d\n", errno, ret);

	ret = read(file, buf, 0x100);
	if (ret < 0) {
		printf("\n2rd read file failed. errno = %d, ret = %d\n", errno, ret);
		goto err;
	} else
		printf("\n3rd read file succeed. errno = %d, ret = %d\n", errno, ret);


	return 0;
err:
	return -1;
}


[-- Attachment #3: Type: text/plain, Size: 150 bytes --]

_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Chen Gang]

[-- Attachment #1: Type: text/plain, Size: 1893 bytes --]

On 05/23/2013 05:12 PM, Geert Uytterhoeven wrote:
> On Thu, May 23, 2013 at 11:05 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
>> > On Thu, May 23, 2013 at 10:40:29AM +0200, Geert Uytterhoeven wrote:
>>> >> On Thu, May 23, 2013 at 9:57 AM, Chen Gang <gang.chen@asianux.com> wrote:
>>>> >> > -config BUG
>>>> >> > -       bool "BUG() support" if EXPERT
>>>> >> > -       default y
>>>> >> > -       help
>>>> >> > -          Disabling this option eliminates support for BUG and WARN, reducing
>>>> >> > -          the size of your kernel image and potentially quietly ignoring
>>>> >> > -          numerous fatal conditions. You should only consider disabling this
>>>> >> > -          option for embedded systems with no facilities for reporting errors.
>>>> >> > -          Just say Y.
>>> >>
>>> >> ... It's about reducing memory size on devices where you can't show bug or
>>> >> warning messages.
>> >
>> > And turning off CONFIG_BUG causes lots of warning messages at compile time
>> > about functions which are returning nothing which shouldn't.
>> >
>> > The problem is: trying to fix that _will_ mean the result is a larger
>> > kernel than if you just do the usual arch-implemented thing of placing
>> > an defined faulting instruction at the BUG() site - which defeats the
>> > purpose of turning off CONFIG_BUG.
> Is __builtin_unreachable() working well these days?

In fact, using __builtin_unreachable() is a standard way for
architectures to implemented their own BUG() (e.g. x86, s390, powerpc,
arm ...)

Before __builtin_unreachable(), must need an inline asm instruction
which architecture specific.

I have test using __builtin_unreachable() without an related asm
instruction before, it prints many unexpected things (please see the
attachment).

So I think, it is not suitable to use it in "asm-generic/bug.h"


Thanks.
-- 
Chen Gang

Asianux Corporation

[-- Attachment #2: test0.c --]
[-- Type: text/plain, Size: 1234 bytes --]

#include <stdio.h>
#include <sys/types.h>
#include <error.h>
#include <errno.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/stat.h>

int main()
{
	int file;
	int ret;
	char buf[0x100];

	file = open("/tmp/work.c", O_RDONLY);
	if (file == -1) {
		printf("\nopen file failed. errno = %d\n", errno);
		goto err;
	} else
		printf("\nopen file succeed.\n");

	printf("before unreachable\n");
	__builtin_unreachable();
	printf("after unreachable\n");

	if (lseek(file, 10, SEEK_END) < 0) {
		printf("\nlseek file failed. errno = %d\n", errno);
		goto err;
	}

	ret = read(file, buf, 0x100);
	if (ret < 0) {
		printf("\n1st read file failed. errno = %d, ret = %d\n", errno, ret);
		goto err;
	} else
		printf("\n1st read file succeed. errno = %d, ret = %d\n", errno, ret);

	ret = read(file, buf, 0x100);
	if (ret < 0) {
		printf("\n2nd read file failed. errno = %d, ret = %d\n", errno, ret);
		goto err;
	} else
		printf("\n2nd read file succeed. errno = %d, ret = %d\n", errno, ret);

	ret = read(file, buf, 0x100);
	if (ret < 0) {
		printf("\n2rd read file failed. errno = %d, ret = %d\n", errno, ret);
		goto err;
	} else
		printf("\n3rd read file succeed. errno = %d, ret = %d\n", errno, ret);


	return 0;
err:
	return -1;
}

[PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Chen Gang]

On 05/23/2013 05:12 PM, Geert Uytterhoeven wrote:
> On Thu, May 23, 2013 at 11:05 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
>> > On Thu, May 23, 2013 at 10:40:29AM +0200, Geert Uytterhoeven wrote:
>>> >> On Thu, May 23, 2013 at 9:57 AM, Chen Gang <gang.chen@asianux.com> wrote:
>>>> >> > -config BUG
>>>> >> > -       bool "BUG() support" if EXPERT
>>>> >> > -       default y
>>>> >> > -       help
>>>> >> > -          Disabling this option eliminates support for BUG and WARN, reducing
>>>> >> > -          the size of your kernel image and potentially quietly ignoring
>>>> >> > -          numerous fatal conditions. You should only consider disabling this
>>>> >> > -          option for embedded systems with no facilities for reporting errors.
>>>> >> > -          Just say Y.
>>> >>
>>> >> ... It's about reducing memory size on devices where you can't show bug or
>>> >> warning messages.
>> >
>> > And turning off CONFIG_BUG causes lots of warning messages at compile time
>> > about functions which are returning nothing which shouldn't.
>> >
>> > The problem is: trying to fix that _will_ mean the result is a larger
>> > kernel than if you just do the usual arch-implemented thing of placing
>> > an defined faulting instruction at the BUG() site - which defeats the
>> > purpose of turning off CONFIG_BUG.
> Is __builtin_unreachable() working well these days?

In fact, using __builtin_unreachable() is a standard way for
architectures to implemented their own BUG() (e.g. x86, s390, powerpc,
arm ...)

Before __builtin_unreachable(), must need an inline asm instruction
which architecture specific.

I have test using __builtin_unreachable() without an related asm
instruction before, it prints many unexpected things (please see the
attachment).

So I think, it is not suitable to use it in "asm-generic/bug.h"


Thanks.
-- 
Chen Gang

Asianux Corporation
-------------- next part --------------
#include <stdio.h>
#include <sys/types.h>
#include <error.h>
#include <errno.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/stat.h>

int main()
{
	int file;
	int ret;
	char buf[0x100];

	file = open("/tmp/work.c", O_RDONLY);
	if (file == -1) {
		printf("\nopen file failed. errno = %d\n", errno);
		goto err;
	} else
		printf("\nopen file succeed.\n");

	printf("before unreachable\n");
	__builtin_unreachable();
	printf("after unreachable\n");

	if (lseek(file, 10, SEEK_END) < 0) {
		printf("\nlseek file failed. errno = %d\n", errno);
		goto err;
	}

	ret = read(file, buf, 0x100);
	if (ret < 0) {
		printf("\n1st read file failed. errno = %d, ret = %d\n", errno, ret);
		goto err;
	} else
		printf("\n1st read file succeed. errno = %d, ret = %d\n", errno, ret);

	ret = read(file, buf, 0x100);
	if (ret < 0) {
		printf("\n2nd read file failed. errno = %d, ret = %d\n", errno, ret);
		goto err;
	} else
		printf("\n2nd read file succeed. errno = %d, ret = %d\n", errno, ret);

	ret = read(file, buf, 0x100);
	if (ret < 0) {
		printf("\n2rd read file failed. errno = %d, ret = %d\n", errno, ret);
		goto err;
	} else
		printf("\n3rd read file succeed. errno = %d, ret = %d\n", errno, ret);


	return 0;
err:
	return -1;
}

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Chen Gang]

[-- Attachment #1: Type: text/plain, Size: 1893 bytes --]

On 05/23/2013 05:12 PM, Geert Uytterhoeven wrote:
> On Thu, May 23, 2013 at 11:05 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
>> > On Thu, May 23, 2013 at 10:40:29AM +0200, Geert Uytterhoeven wrote:
>>> >> On Thu, May 23, 2013 at 9:57 AM, Chen Gang <gang.chen@asianux.com> wrote:
>>>> >> > -config BUG
>>>> >> > -       bool "BUG() support" if EXPERT
>>>> >> > -       default y
>>>> >> > -       help
>>>> >> > -          Disabling this option eliminates support for BUG and WARN, reducing
>>>> >> > -          the size of your kernel image and potentially quietly ignoring
>>>> >> > -          numerous fatal conditions. You should only consider disabling this
>>>> >> > -          option for embedded systems with no facilities for reporting errors.
>>>> >> > -          Just say Y.
>>> >>
>>> >> ... It's about reducing memory size on devices where you can't show bug or
>>> >> warning messages.
>> >
>> > And turning off CONFIG_BUG causes lots of warning messages at compile time
>> > about functions which are returning nothing which shouldn't.
>> >
>> > The problem is: trying to fix that _will_ mean the result is a larger
>> > kernel than if you just do the usual arch-implemented thing of placing
>> > an defined faulting instruction at the BUG() site - which defeats the
>> > purpose of turning off CONFIG_BUG.
> Is __builtin_unreachable() working well these days?

In fact, using __builtin_unreachable() is a standard way for
architectures to implemented their own BUG() (e.g. x86, s390, powerpc,
arm ...)

Before __builtin_unreachable(), must need an inline asm instruction
which architecture specific.

I have test using __builtin_unreachable() without an related asm
instruction before, it prints many unexpected things (please see the
attachment).

So I think, it is not suitable to use it in "asm-generic/bug.h"


Thanks.
-- 
Chen Gang

Asianux Corporation

[-- Attachment #2: test0.c --]
[-- Type: text/plain, Size: 1234 bytes --]

#include <stdio.h>
#include <sys/types.h>
#include <error.h>
#include <errno.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/stat.h>

int main()
{
	int file;
	int ret;
	char buf[0x100];

	file = open("/tmp/work.c", O_RDONLY);
	if (file == -1) {
		printf("\nopen file failed. errno = %d\n", errno);
		goto err;
	} else
		printf("\nopen file succeed.\n");

	printf("before unreachable\n");
	__builtin_unreachable();
	printf("after unreachable\n");

	if (lseek(file, 10, SEEK_END) < 0) {
		printf("\nlseek file failed. errno = %d\n", errno);
		goto err;
	}

	ret = read(file, buf, 0x100);
	if (ret < 0) {
		printf("\n1st read file failed. errno = %d, ret = %d\n", errno, ret);
		goto err;
	} else
		printf("\n1st read file succeed. errno = %d, ret = %d\n", errno, ret);

	ret = read(file, buf, 0x100);
	if (ret < 0) {
		printf("\n2nd read file failed. errno = %d, ret = %d\n", errno, ret);
		goto err;
	} else
		printf("\n2nd read file succeed. errno = %d, ret = %d\n", errno, ret);

	ret = read(file, buf, 0x100);
	if (ret < 0) {
		printf("\n2rd read file failed. errno = %d, ret = %d\n", errno, ret);
		goto err;
	} else
		printf("\n3rd read file succeed. errno = %d, ret = %d\n", errno, ret);


	return 0;
err:
	return -1;
}

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Eric W. Biederman]

Arnd Bergmann <arnd@arndb.de> writes:

> On Thursday 23 May 2013, Geert Uytterhoeven wrote:
>> > The problem is: trying to fix that will mean the result is a larger
>> > kernel than if you just do the usual arch-implemented thing of placing
>> > an defined faulting instruction at the BUG() site - which defeats the
>> > purpose of turning off CONFIG_BUG.
>> 
>> Is __builtin_unreachable() working well these days?
>> 
>
> Hmm, I just tried the trivial patch below, which seemed to do the right thing.
> Needs a little more investigation, but that might actually be the correct
> solution. I thought that at some point __builtin_unreachable() was the same
> as "do {} while (1)", but this is not the case with the gcc I was using --
> it just tells gcc that we don't expect to ever get here.

Yes.

We already have this abstracted in compiler.h as the macro unreachable,
so the slight modification of your patch below should handle this case.

For compilers without __builtin_unreachable() unreachable() expands to
do {} while(1) but an infinite loop seems reasonable and preserves the
semantics of the code, unlike the current noop that is do {} while(0).

> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
index 7d10f96..9afff7d 100644
--- a/include/asm-generic/bug.h
+++ b/include/asm-generic/bug.h
@@ -108,11 +108,11 @@ extern void warn_slowpath_null(const char *file, const int line);
 
 #else /* !CONFIG_BUG */
 #ifndef HAVE_ARCH_BUG
-#define BUG() do {} while(0)
+#define BUG() unreachable ()
 #endif
 
 #ifndef HAVE_ARCH_BUG_ON
-#define BUG_ON(condition) do { if (condition) ; } while(0)
+#define BUG_ON(condition) do { if (condition) unreachable(); } while(0)
 #endif
 
 #ifndef HAVE_ARCH_WARN_ON

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Eric W. Biederman]

Arnd Bergmann <arnd@arndb.de> writes:

> On Thursday 23 May 2013, Geert Uytterhoeven wrote:
>> > The problem is: trying to fix that will mean the result is a larger
>> > kernel than if you just do the usual arch-implemented thing of placing
>> > an defined faulting instruction at the BUG() site - which defeats the
>> > purpose of turning off CONFIG_BUG.
>> 
>> Is __builtin_unreachable() working well these days?
>> 
>
> Hmm, I just tried the trivial patch below, which seemed to do the right thing.
> Needs a little more investigation, but that might actually be the correct
> solution. I thought that at some point __builtin_unreachable() was the same
> as "do {} while (1)", but this is not the case with the gcc I was using --
> it just tells gcc that we don't expect to ever get here.

Yes.

We already have this abstracted in compiler.h as the macro unreachable,
so the slight modification of your patch below should handle this case.

For compilers without __builtin_unreachable() unreachable() expands to
do {} while(1) but an infinite loop seems reasonable and preserves the
semantics of the code, unlike the current noop that is do {} while(0).

> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
index 7d10f96..9afff7d 100644
--- a/include/asm-generic/bug.h
+++ b/include/asm-generic/bug.h
@@ -108,11 +108,11 @@ extern void warn_slowpath_null(const char *file, const int line);
 
 #else /* !CONFIG_BUG */
 #ifndef HAVE_ARCH_BUG
-#define BUG() do {} while(0)
+#define BUG() unreachable ()
 #endif
 
 #ifndef HAVE_ARCH_BUG_ON
-#define BUG_ON(condition) do { if (condition) ; } while(0)
+#define BUG_ON(condition) do { if (condition) unreachable(); } while(0)
 #endif
 
 #ifndef HAVE_ARCH_WARN_ON

[PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Eric W. Biederman]

Arnd Bergmann <arnd@arndb.de> writes:

> On Thursday 23 May 2013, Geert Uytterhoeven wrote:
>> > The problem is: trying to fix that will mean the result is a larger
>> > kernel than if you just do the usual arch-implemented thing of placing
>> > an defined faulting instruction at the BUG() site - which defeats the
>> > purpose of turning off CONFIG_BUG.
>> 
>> Is __builtin_unreachable() working well these days?
>> 
>
> Hmm, I just tried the trivial patch below, which seemed to do the right thing.
> Needs a little more investigation, but that might actually be the correct
> solution. I thought that at some point __builtin_unreachable() was the same
> as "do {} while (1)", but this is not the case with the gcc I was using --
> it just tells gcc that we don't expect to ever get here.

Yes.

We already have this abstracted in compiler.h as the macro unreachable,
so the slight modification of your patch below should handle this case.

For compilers without __builtin_unreachable() unreachable() expands to
do {} while(1) but an infinite loop seems reasonable and preserves the
semantics of the code, unlike the current noop that is do {} while(0).

> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
index 7d10f96..9afff7d 100644
--- a/include/asm-generic/bug.h
+++ b/include/asm-generic/bug.h
@@ -108,11 +108,11 @@ extern void warn_slowpath_null(const char *file, const int line);
 
 #else /* !CONFIG_BUG */
 #ifndef HAVE_ARCH_BUG
-#define BUG() do {} while(0)
+#define BUG() unreachable ()
 #endif
 
 #ifndef HAVE_ARCH_BUG_ON
-#define BUG_ON(condition) do { if (condition) ; } while(0)
+#define BUG_ON(condition) do { if (condition) unreachable(); } while(0)
 #endif
 
 #ifndef HAVE_ARCH_WARN_ON

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Eric W. Biederman]

Arnd Bergmann <arnd@arndb.de> writes:

> On Thursday 23 May 2013, Geert Uytterhoeven wrote:
>> > The problem is: trying to fix that will mean the result is a larger
>> > kernel than if you just do the usual arch-implemented thing of placing
>> > an defined faulting instruction at the BUG() site - which defeats the
>> > purpose of turning off CONFIG_BUG.
>> 
>> Is __builtin_unreachable() working well these days?
>> 
>
> Hmm, I just tried the trivial patch below, which seemed to do the right thing.
> Needs a little more investigation, but that might actually be the correct
> solution. I thought that at some point __builtin_unreachable() was the same
> as "do {} while (1)", but this is not the case with the gcc I was using --
> it just tells gcc that we don't expect to ever get here.

Yes.

We already have this abstracted in compiler.h as the macro unreachable,
so the slight modification of your patch below should handle this case.

For compilers without __builtin_unreachable() unreachable() expands to
do {} while(1) but an infinite loop seems reasonable and preserves the
semantics of the code, unlike the current noop that is do {} while(0).

> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
index 7d10f96..9afff7d 100644
--- a/include/asm-generic/bug.h
+++ b/include/asm-generic/bug.h
@@ -108,11 +108,11 @@ extern void warn_slowpath_null(const char *file, const int line);
 
 #else /* !CONFIG_BUG */
 #ifndef HAVE_ARCH_BUG
-#define BUG() do {} while(0)
+#define BUG() unreachable ()
 #endif
 
 #ifndef HAVE_ARCH_BUG_ON
-#define BUG_ON(condition) do { if (condition) ; } while(0)
+#define BUG_ON(condition) do { if (condition) unreachable(); } while(0)
 #endif
 
 #ifndef HAVE_ARCH_WARN_ON

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Russell King - ARM Linux]

On Thu, May 23, 2013 at 03:09:50AM -0700, Eric W. Biederman wrote:
> Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> writes:
> 
> > On Thursday 23 May 2013, Geert Uytterhoeven wrote:
> >> > The problem is: trying to fix that will mean the result is a larger
> >> > kernel than if you just do the usual arch-implemented thing of placing
> >> > an defined faulting instruction at the BUG() site - which defeats the
> >> > purpose of turning off CONFIG_BUG.
> >> 
> >> Is __builtin_unreachable() working well these days?
> >> 
> >
> > Hmm, I just tried the trivial patch below, which seemed to do the right thing.
> > Needs a little more investigation, but that might actually be the correct
> > solution. I thought that at some point __builtin_unreachable() was the same
> > as "do {} while (1)", but this is not the case with the gcc I was using --
> > it just tells gcc that we don't expect to ever get here.
> 
> Yes.
> 
> We already have this abstracted in compiler.h as the macro unreachable,
> so the slight modification of your patch below should handle this case.
> 
> For compilers without __builtin_unreachable() unreachable() expands to
> do {} while(1) but an infinite loop seems reasonable and preserves the
> semantics of the code, unlike the current noop that is do {} while(0).

Semantics of the code really don't come in to it if you use unreachable().
unreachable() is an effective do { } while (0) to the compiler.  It just
doesn't warn about it anymore.  It's actually worse than that - it's
permission to the compiler to just stop considering flow control at that
point and do anything it likes with the following instruction slot.

What __builtin_unreachable() means to the compiler is "we will *never*
get here".  That isn't the case for BUG() - BUG() means "we hope that
we will never get here, but we might, and if we do your data is in
grave danger."

We should either have something at that point (like a call to a function
which panics) or remove the ability to turn off CONFIG_BUG and anyone who
cares about kernel size needs to come up with a single trapping
instruction BUG() implementation.

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Russell King - ARM Linux]

On Thu, May 23, 2013 at 03:09:50AM -0700, Eric W. Biederman wrote:
> Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> writes:
> 
> > On Thursday 23 May 2013, Geert Uytterhoeven wrote:
> >> > The problem is: trying to fix that will mean the result is a larger
> >> > kernel than if you just do the usual arch-implemented thing of placing
> >> > an defined faulting instruction at the BUG() site - which defeats the
> >> > purpose of turning off CONFIG_BUG.
> >> 
> >> Is __builtin_unreachable() working well these days?
> >> 
> >
> > Hmm, I just tried the trivial patch below, which seemed to do the right thing.
> > Needs a little more investigation, but that might actually be the correct
> > solution. I thought that at some point __builtin_unreachable() was the same
> > as "do {} while (1)", but this is not the case with the gcc I was using --
> > it just tells gcc that we don't expect to ever get here.
> 
> Yes.
> 
> We already have this abstracted in compiler.h as the macro unreachable,
> so the slight modification of your patch below should handle this case.
> 
> For compilers without __builtin_unreachable() unreachable() expands to
> do {} while(1) but an infinite loop seems reasonable and preserves the
> semantics of the code, unlike the current noop that is do {} while(0).

Semantics of the code really don't come in to it if you use unreachable().
unreachable() is an effective do { } while (0) to the compiler.  It just
doesn't warn about it anymore.  It's actually worse than that - it's
permission to the compiler to just stop considering flow control at that
point and do anything it likes with the following instruction slot.

What __builtin_unreachable() means to the compiler is "we will *never*
get here".  That isn't the case for BUG() - BUG() means "we hope that
we will never get here, but we might, and if we do your data is in
grave danger."

We should either have something at that point (like a call to a function
which panics) or remove the ability to turn off CONFIG_BUG and anyone who
cares about kernel size needs to come up with a single trapping
instruction BUG() implementation.

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Russell King - ARM Linux]

On Thu, May 23, 2013 at 03:09:50AM -0700, Eric W. Biederman wrote:
> Arnd Bergmann <arnd@arndb.de> writes:
> 
> > On Thursday 23 May 2013, Geert Uytterhoeven wrote:
> >> > The problem is: trying to fix that will mean the result is a larger
> >> > kernel than if you just do the usual arch-implemented thing of placing
> >> > an defined faulting instruction at the BUG() site - which defeats the
> >> > purpose of turning off CONFIG_BUG.
> >> 
> >> Is __builtin_unreachable() working well these days?
> >> 
> >
> > Hmm, I just tried the trivial patch below, which seemed to do the right thing.
> > Needs a little more investigation, but that might actually be the correct
> > solution. I thought that at some point __builtin_unreachable() was the same
> > as "do {} while (1)", but this is not the case with the gcc I was using --
> > it just tells gcc that we don't expect to ever get here.
> 
> Yes.
> 
> We already have this abstracted in compiler.h as the macro unreachable,
> so the slight modification of your patch below should handle this case.
> 
> For compilers without __builtin_unreachable() unreachable() expands to
> do {} while(1) but an infinite loop seems reasonable and preserves the
> semantics of the code, unlike the current noop that is do {} while(0).

Semantics of the code really don't come in to it if you use unreachable().
unreachable() is an effective do { } while (0) to the compiler.  It just
doesn't warn about it anymore.  It's actually worse than that - it's
permission to the compiler to just stop considering flow control at that
point and do anything it likes with the following instruction slot.

What __builtin_unreachable() means to the compiler is "we will *never*
get here".  That isn't the case for BUG() - BUG() means "we hope that
we will never get here, but we might, and if we do your data is in
grave danger."

We should either have something at that point (like a call to a function
which panics) or remove the ability to turn off CONFIG_BUG and anyone who
cares about kernel size needs to come up with a single trapping
instruction BUG() implementation.

[PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Russell King - ARM Linux]

On Thu, May 23, 2013 at 03:09:50AM -0700, Eric W. Biederman wrote:
> Arnd Bergmann <arnd@arndb.de> writes:
> 
> > On Thursday 23 May 2013, Geert Uytterhoeven wrote:
> >> > The problem is: trying to fix that will mean the result is a larger
> >> > kernel than if you just do the usual arch-implemented thing of placing
> >> > an defined faulting instruction at the BUG() site - which defeats the
> >> > purpose of turning off CONFIG_BUG.
> >> 
> >> Is __builtin_unreachable() working well these days?
> >> 
> >
> > Hmm, I just tried the trivial patch below, which seemed to do the right thing.
> > Needs a little more investigation, but that might actually be the correct
> > solution. I thought that at some point __builtin_unreachable() was the same
> > as "do {} while (1)", but this is not the case with the gcc I was using --
> > it just tells gcc that we don't expect to ever get here.
> 
> Yes.
> 
> We already have this abstracted in compiler.h as the macro unreachable,
> so the slight modification of your patch below should handle this case.
> 
> For compilers without __builtin_unreachable() unreachable() expands to
> do {} while(1) but an infinite loop seems reasonable and preserves the
> semantics of the code, unlike the current noop that is do {} while(0).

Semantics of the code really don't come in to it if you use unreachable().
unreachable() is an effective do { } while (0) to the compiler.  It just
doesn't warn about it anymore.  It's actually worse than that - it's
permission to the compiler to just stop considering flow control at that
point and do anything it likes with the following instruction slot.

What __builtin_unreachable() means to the compiler is "we will *never*
get here".  That isn't the case for BUG() - BUG() means "we hope that
we will never get here, but we might, and if we do your data is in
grave danger."

We should either have something at that point (like a call to a function
which panics) or remove the ability to turn off CONFIG_BUG and anyone who
cares about kernel size needs to come up with a single trapping
instruction BUG() implementation.

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Russell King - ARM Linux]

On Thu, May 23, 2013 at 03:09:50AM -0700, Eric W. Biederman wrote:
> Arnd Bergmann <arnd@arndb.de> writes:
> 
> > On Thursday 23 May 2013, Geert Uytterhoeven wrote:
> >> > The problem is: trying to fix that will mean the result is a larger
> >> > kernel than if you just do the usual arch-implemented thing of placing
> >> > an defined faulting instruction at the BUG() site - which defeats the
> >> > purpose of turning off CONFIG_BUG.
> >> 
> >> Is __builtin_unreachable() working well these days?
> >> 
> >
> > Hmm, I just tried the trivial patch below, which seemed to do the right thing.
> > Needs a little more investigation, but that might actually be the correct
> > solution. I thought that at some point __builtin_unreachable() was the same
> > as "do {} while (1)", but this is not the case with the gcc I was using --
> > it just tells gcc that we don't expect to ever get here.
> 
> Yes.
> 
> We already have this abstracted in compiler.h as the macro unreachable,
> so the slight modification of your patch below should handle this case.
> 
> For compilers without __builtin_unreachable() unreachable() expands to
> do {} while(1) but an infinite loop seems reasonable and preserves the
> semantics of the code, unlike the current noop that is do {} while(0).

Semantics of the code really don't come in to it if you use unreachable().
unreachable() is an effective do { } while (0) to the compiler.  It just
doesn't warn about it anymore.  It's actually worse than that - it's
permission to the compiler to just stop considering flow control at that
point and do anything it likes with the following instruction slot.

What __builtin_unreachable() means to the compiler is "we will *never*
get here".  That isn't the case for BUG() - BUG() means "we hope that
we will never get here, but we might, and if we do your data is in
grave danger."

We should either have something at that point (like a call to a function
which panics) or remove the ability to turn off CONFIG_BUG and anyone who
cares about kernel size needs to come up with a single trapping
instruction BUG() implementation.

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Russell King - ARM Linux]

On Thu, May 23, 2013 at 03:09:50AM -0700, Eric W. Biederman wrote:
> Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> writes:
> 
> > On Thursday 23 May 2013, Geert Uytterhoeven wrote:
> >> > The problem is: trying to fix that will mean the result is a larger
> >> > kernel than if you just do the usual arch-implemented thing of placing
> >> > an defined faulting instruction at the BUG() site - which defeats the
> >> > purpose of turning off CONFIG_BUG.
> >> 
> >> Is __builtin_unreachable() working well these days?
> >> 
> >
> > Hmm, I just tried the trivial patch below, which seemed to do the right thing.
> > Needs a little more investigation, but that might actually be the correct
> > solution. I thought that at some point __builtin_unreachable() was the same
> > as "do {} while (1)", but this is not the case with the gcc I was using --
> > it just tells gcc that we don't expect to ever get here.
> 
> Yes.
> 
> We already have this abstracted in compiler.h as the macro unreachable,
> so the slight modification of your patch below should handle this case.
> 
> For compilers without __builtin_unreachable() unreachable() expands to
> do {} while(1) but an infinite loop seems reasonable and preserves the
> semantics of the code, unlike the current noop that is do {} while(0).

Semantics of the code really don't come in to it if you use unreachable().
unreachable() is an effective do { } while (0) to the compiler.  It just
doesn't warn about it anymore.  It's actually worse than that - it's
permission to the compiler to just stop considering flow control at that
point and do anything it likes with the following instruction slot.

What __builtin_unreachable() means to the compiler is "we will *never*
get here".  That isn't the case for BUG() - BUG() means "we hope that
we will never get here, but we might, and if we do your data is in
grave danger."

We should either have something at that point (like a call to a function
which panics) or remove the ability to turn off CONFIG_BUG and anyone who
cares about kernel size needs to come up with a single trapping
instruction BUG() implementation.

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Chen Gang]

On 05/23/2013 06:04 PM, Russell King - ARM Linux wrote:
> So, if you want to use this, then you should update the CONFIG_BUG text
> to include a warning to this effect:
> 
>      Warning: if CONFIG_BUG is turned off, and control flow reaches
>      a BUG(), the system behaviour will be undefined.
> 
> so that people can make an informed choice about this, because at the
> moment:
> 
>           Disabling this option eliminates support for BUG and WARN, reducing
>           the size of your kernel image and potentially quietly ignoring
>           numerous fatal conditions. You should only consider disabling this
>           option for embedded systems with no facilities for reporting errors.
>           Just say Y.
> 
> will become completely misleading.  Turning this option off will _not_
> result in "quietly ignoring numerous fatal conditions".
> 
> And I come back to one of my previous arguments - is it not better to
> panic() if we hit one of these conditions so that the system can try to
> do a panic-reboot rather than continue blindly into the unknown?

But I still suggest to delete CONFIG_BUG in common kernel.

Since currently, disable 'CONFIG_BUG' is not a common features (most of
architectures are always enable it), it is only belongs to some
architectures specific features (may some embedded systems).

It is not suitable to still let 'CONFIG_BUG' exist in
"asm-generic/bug.h" which is only for common features.

And each architecture can customize their own BUG(), if one architecture
wants to Disabling this option, let it specify its own BUG().

So, most of architectures need not consider this issue again.


Thanks.
-- 
Chen Gang

Asianux Corporation

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Chen Gang]

On 05/23/2013 06:04 PM, Russell King - ARM Linux wrote:
> So, if you want to use this, then you should update the CONFIG_BUG text
> to include a warning to this effect:
> 
>      Warning: if CONFIG_BUG is turned off, and control flow reaches
>      a BUG(), the system behaviour will be undefined.
> 
> so that people can make an informed choice about this, because at the
> moment:
> 
>           Disabling this option eliminates support for BUG and WARN, reducing
>           the size of your kernel image and potentially quietly ignoring
>           numerous fatal conditions. You should only consider disabling this
>           option for embedded systems with no facilities for reporting errors.
>           Just say Y.
> 
> will become completely misleading.  Turning this option off will _not_
> result in "quietly ignoring numerous fatal conditions".
> 
> And I come back to one of my previous arguments - is it not better to
> panic() if we hit one of these conditions so that the system can try to
> do a panic-reboot rather than continue blindly into the unknown?

But I still suggest to delete CONFIG_BUG in common kernel.

Since currently, disable 'CONFIG_BUG' is not a common features (most of
architectures are always enable it), it is only belongs to some
architectures specific features (may some embedded systems).

It is not suitable to still let 'CONFIG_BUG' exist in
"asm-generic/bug.h" which is only for common features.

And each architecture can customize their own BUG(), if one architecture
wants to Disabling this option, let it specify its own BUG().

So, most of architectures need not consider this issue again.


Thanks.
-- 
Chen Gang

Asianux Corporation

[PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Chen Gang]

On 05/23/2013 06:04 PM, Russell King - ARM Linux wrote:
> So, if you want to use this, then you should update the CONFIG_BUG text
> to include a warning to this effect:
> 
>      Warning: if CONFIG_BUG is turned off, and control flow reaches
>      a BUG(), the system behaviour will be undefined.
> 
> so that people can make an informed choice about this, because at the
> moment:
> 
>           Disabling this option eliminates support for BUG and WARN, reducing
>           the size of your kernel image and potentially quietly ignoring
>           numerous fatal conditions. You should only consider disabling this
>           option for embedded systems with no facilities for reporting errors.
>           Just say Y.
> 
> will become completely misleading.  Turning this option off will _not_
> result in "quietly ignoring numerous fatal conditions".
> 
> And I come back to one of my previous arguments - is it not better to
> panic() if we hit one of these conditions so that the system can try to
> do a panic-reboot rather than continue blindly into the unknown?

But I still suggest to delete CONFIG_BUG in common kernel.

Since currently, disable 'CONFIG_BUG' is not a common features (most of
architectures are always enable it), it is only belongs to some
architectures specific features (may some embedded systems).

It is not suitable to still let 'CONFIG_BUG' exist in
"asm-generic/bug.h" which is only for common features.

And each architecture can customize their own BUG(), if one architecture
wants to Disabling this option, let it specify its own BUG().

So, most of architectures need not consider this issue again.


Thanks.
-- 
Chen Gang

Asianux Corporation

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Chen Gang]

On 05/23/2013 06:04 PM, Russell King - ARM Linux wrote:
> So, if you want to use this, then you should update the CONFIG_BUG text
> to include a warning to this effect:
> 
>      Warning: if CONFIG_BUG is turned off, and control flow reaches
>      a BUG(), the system behaviour will be undefined.
> 
> so that people can make an informed choice about this, because at the
> moment:
> 
>           Disabling this option eliminates support for BUG and WARN, reducing
>           the size of your kernel image and potentially quietly ignoring
>           numerous fatal conditions. You should only consider disabling this
>           option for embedded systems with no facilities for reporting errors.
>           Just say Y.
> 
> will become completely misleading.  Turning this option off will _not_
> result in "quietly ignoring numerous fatal conditions".
> 
> And I come back to one of my previous arguments - is it not better to
> panic() if we hit one of these conditions so that the system can try to
> do a panic-reboot rather than continue blindly into the unknown?

But I still suggest to delete CONFIG_BUG in common kernel.

Since currently, disable 'CONFIG_BUG' is not a common features (most of
architectures are always enable it), it is only belongs to some
architectures specific features (may some embedded systems).

It is not suitable to still let 'CONFIG_BUG' exist in
"asm-generic/bug.h" which is only for common features.

And each architecture can customize their own BUG(), if one architecture
wants to Disabling this option, let it specify its own BUG().

So, most of architectures need not consider this issue again.


Thanks.
-- 
Chen Gang

Asianux Corporation

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Arnd Bergmann]

On Thursday 23 May 2013, Russell King - ARM Linux wrote:
> So, if you want to use this, then you should update the CONFIG_BUG text
> to include a warning to this effect:
> 
>      Warning: if CONFIG_BUG is turned off, and control flow reaches
>      a BUG(), the system behaviour will be undefined.
> 
> so that people can make an informed choice about this, because at the
> moment:
> 
>           Disabling this option eliminates support for BUG and WARN, reducing
>           the size of your kernel image and potentially quietly ignoring
>           numerous fatal conditions. You should only consider disabling this
>           option for embedded systems with no facilities for reporting errors.
>           Just say Y.
> 
> will become completely misleading.  Turning this option off will not
> result in "quietly ignoring numerous fatal conditions".

I must be missing something, to me the two descriptions mean the same thing.

> And I come back to one of my previous arguments - is it not better to
> panic() if we hit one of these conditions so that the system can try to
> do a panic-reboot rather than continue blindly into the unknown?

I think this all comes from the 'linux-tiny' project that tried to squeeze
out the last bits of kernel object code size at some point. The idea was
that if you have code like

	BUG_ON(something_unexpected_happened());

or

	switch (my_enum) {
	case FOO:
		return f1();
	case BAR:
		return f2();
	default:
		BUG();
	}

You don't just want to avoid the code for printing the bug message and
the invalid instruction, we also want the compiler to not emit the 
function call or check the enum for unexpected values. The meaning of
BUG() is really that person writing that statement was sure it cannot
happen unless there is a bug in the kernel, which has likely already
corrupted data. Printing a diagnostic at this point is nice if someone
is there to look at it, but letting the kernel do further actions that
may be undefined is not going to make things worse.

	Arnd

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Arnd Bergmann]

On Thursday 23 May 2013, Russell King - ARM Linux wrote:
> So, if you want to use this, then you should update the CONFIG_BUG text
> to include a warning to this effect:
> 
>      Warning: if CONFIG_BUG is turned off, and control flow reaches
>      a BUG(), the system behaviour will be undefined.
> 
> so that people can make an informed choice about this, because at the
> moment:
> 
>           Disabling this option eliminates support for BUG and WARN, reducing
>           the size of your kernel image and potentially quietly ignoring
>           numerous fatal conditions. You should only consider disabling this
>           option for embedded systems with no facilities for reporting errors.
>           Just say Y.
> 
> will become completely misleading.  Turning this option off will not
> result in "quietly ignoring numerous fatal conditions".

I must be missing something, to me the two descriptions mean the same thing.

> And I come back to one of my previous arguments - is it not better to
> panic() if we hit one of these conditions so that the system can try to
> do a panic-reboot rather than continue blindly into the unknown?

I think this all comes from the 'linux-tiny' project that tried to squeeze
out the last bits of kernel object code size at some point. The idea was
that if you have code like

	BUG_ON(something_unexpected_happened());

or

	switch (my_enum) {
	case FOO:
		return f1();
	case BAR:
		return f2();
	default:
		BUG();
	}

You don't just want to avoid the code for printing the bug message and
the invalid instruction, we also want the compiler to not emit the 
function call or check the enum for unexpected values. The meaning of
BUG() is really that person writing that statement was sure it cannot
happen unless there is a bug in the kernel, which has likely already
corrupted data. Printing a diagnostic at this point is nice if someone
is there to look at it, but letting the kernel do further actions that
may be undefined is not going to make things worse.

	Arnd

[PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Arnd Bergmann]

On Thursday 23 May 2013, Russell King - ARM Linux wrote:
> So, if you want to use this, then you should update the CONFIG_BUG text
> to include a warning to this effect:
> 
>      Warning: if CONFIG_BUG is turned off, and control flow reaches
>      a BUG(), the system behaviour will be undefined.
> 
> so that people can make an informed choice about this, because at the
> moment:
> 
>           Disabling this option eliminates support for BUG and WARN, reducing
>           the size of your kernel image and potentially quietly ignoring
>           numerous fatal conditions. You should only consider disabling this
>           option for embedded systems with no facilities for reporting errors.
>           Just say Y.
> 
> will become completely misleading.  Turning this option off will not
> result in "quietly ignoring numerous fatal conditions".

I must be missing something, to me the two descriptions mean the same thing.

> And I come back to one of my previous arguments - is it not better to
> panic() if we hit one of these conditions so that the system can try to
> do a panic-reboot rather than continue blindly into the unknown?

I think this all comes from the 'linux-tiny' project that tried to squeeze
out the last bits of kernel object code size at some point. The idea was
that if you have code like

	BUG_ON(something_unexpected_happened());

or

	switch (my_enum) {
	case FOO:
		return f1();
	case BAR:
		return f2();
	default:
		BUG();
	}

You don't just want to avoid the code for printing the bug message and
the invalid instruction, we also want the compiler to not emit the 
function call or check the enum for unexpected values. The meaning of
BUG() is really that person writing that statement was sure it cannot
happen unless there is a bug in the kernel, which has likely already
corrupted data. Printing a diagnostic at this point is nice if someone
is there to look at it, but letting the kernel do further actions that
may be undefined is not going to make things worse.

	Arnd

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Arnd Bergmann]

On Thursday 23 May 2013, Russell King - ARM Linux wrote:
> So, if you want to use this, then you should update the CONFIG_BUG text
> to include a warning to this effect:
> 
>      Warning: if CONFIG_BUG is turned off, and control flow reaches
>      a BUG(), the system behaviour will be undefined.
> 
> so that people can make an informed choice about this, because at the
> moment:
> 
>           Disabling this option eliminates support for BUG and WARN, reducing
>           the size of your kernel image and potentially quietly ignoring
>           numerous fatal conditions. You should only consider disabling this
>           option for embedded systems with no facilities for reporting errors.
>           Just say Y.
> 
> will become completely misleading.  Turning this option off will not
> result in "quietly ignoring numerous fatal conditions".

I must be missing something, to me the two descriptions mean the same thing.

> And I come back to one of my previous arguments - is it not better to
> panic() if we hit one of these conditions so that the system can try to
> do a panic-reboot rather than continue blindly into the unknown?

I think this all comes from the 'linux-tiny' project that tried to squeeze
out the last bits of kernel object code size at some point. The idea was
that if you have code like

	BUG_ON(something_unexpected_happened());

or

	switch (my_enum) {
	case FOO:
		return f1();
	case BAR:
		return f2();
	default:
		BUG();
	}

You don't just want to avoid the code for printing the bug message and
the invalid instruction, we also want the compiler to not emit the 
function call or check the enum for unexpected values. The meaning of
BUG() is really that person writing that statement was sure it cannot
happen unless there is a bug in the kernel, which has likely already
corrupted data. Printing a diagnostic at this point is nice if someone
is there to look at it, but letting the kernel do further actions that
may be undefined is not going to make things worse.

	Arnd
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Chen Gang]

On 05/23/2013 06:59 PM, Arnd Bergmann wrote:
> You don't just want to avoid the code for printing the bug message and
> the invalid instruction, we also want the compiler to not emit the 
> function call or check the enum for unexpected values. The meaning of
> BUG() is really that person writing that statement was sure it cannot
> happen unless there is a bug in the kernel, which has likely already
> corrupted data. Printing a diagnostic at this point is nice if someone
> is there to look at it, but letting the kernel do further actions that
> may be undefined is not going to make things worse.

So I think neither unreachable() nor panic() are suitable for this
condition.

I guess 'CONFIG_BUG' is not belong to common features, now (and in the
future), so it is not suitable still exist in "asm-generic/bug.h", need
remove it firstly.

And then let the specific architectures to implement their own BUG(), if
they want some special features.

SO most of arches can skip this issue.


Thanks.
-- 
Chen Gang

Asianux Corporation

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Chen Gang]

On 05/23/2013 06:59 PM, Arnd Bergmann wrote:
> You don't just want to avoid the code for printing the bug message and
> the invalid instruction, we also want the compiler to not emit the 
> function call or check the enum for unexpected values. The meaning of
> BUG() is really that person writing that statement was sure it cannot
> happen unless there is a bug in the kernel, which has likely already
> corrupted data. Printing a diagnostic at this point is nice if someone
> is there to look at it, but letting the kernel do further actions that
> may be undefined is not going to make things worse.

So I think neither unreachable() nor panic() are suitable for this
condition.

I guess 'CONFIG_BUG' is not belong to common features, now (and in the
future), so it is not suitable still exist in "asm-generic/bug.h", need
remove it firstly.

And then let the specific architectures to implement their own BUG(), if
they want some special features.

SO most of arches can skip this issue.


Thanks.
-- 
Chen Gang

Asianux Corporation

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Chen Gang]

On 05/23/2013 06:59 PM, Arnd Bergmann wrote:
> You don't just want to avoid the code for printing the bug message and
> the invalid instruction, we also want the compiler to not emit the 
> function call or check the enum for unexpected values. The meaning of
> BUG() is really that person writing that statement was sure it cannot
> happen unless there is a bug in the kernel, which has likely already
> corrupted data. Printing a diagnostic at this point is nice if someone
> is there to look at it, but letting the kernel do further actions that
> may be undefined is not going to make things worse.

So I think neither unreachable() nor panic() are suitable for this
condition.

I guess 'CONFIG_BUG' is not belong to common features, now (and in the
future), so it is not suitable still exist in "asm-generic/bug.h", need
remove it firstly.

And then let the specific architectures to implement their own BUG(), if
they want some special features.

SO most of arches can skip this issue.


Thanks.
-- 
Chen Gang

Asianux Corporation

[PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Chen Gang]

On 05/23/2013 06:59 PM, Arnd Bergmann wrote:
> You don't just want to avoid the code for printing the bug message and
> the invalid instruction, we also want the compiler to not emit the 
> function call or check the enum for unexpected values. The meaning of
> BUG() is really that person writing that statement was sure it cannot
> happen unless there is a bug in the kernel, which has likely already
> corrupted data. Printing a diagnostic at this point is nice if someone
> is there to look at it, but letting the kernel do further actions that
> may be undefined is not going to make things worse.

So I think neither unreachable() nor panic() are suitable for this
condition.

I guess 'CONFIG_BUG' is not belong to common features, now (and in the
future), so it is not suitable still exist in "asm-generic/bug.h", need
remove it firstly.

And then let the specific architectures to implement their own BUG(), if
they want some special features.

SO most of arches can skip this issue.


Thanks.
-- 
Chen Gang

Asianux Corporation

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Chen Gang]

On 05/23/2013 06:59 PM, Arnd Bergmann wrote:
> You don't just want to avoid the code for printing the bug message and
> the invalid instruction, we also want the compiler to not emit the 
> function call or check the enum for unexpected values. The meaning of
> BUG() is really that person writing that statement was sure it cannot
> happen unless there is a bug in the kernel, which has likely already
> corrupted data. Printing a diagnostic at this point is nice if someone
> is there to look at it, but letting the kernel do further actions that
> may be undefined is not going to make things worse.

So I think neither unreachable() nor panic() are suitable for this
condition.

I guess 'CONFIG_BUG' is not belong to common features, now (and in the
future), so it is not suitable still exist in "asm-generic/bug.h", need
remove it firstly.

And then let the specific architectures to implement their own BUG(), if
they want some special features.

SO most of arches can skip this issue.


Thanks.
-- 
Chen Gang

Asianux Corporation

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Russell King - ARM Linux]

On Thu, May 23, 2013 at 12:59:43PM +0200, Arnd Bergmann wrote:
> On Thursday 23 May 2013, Russell King - ARM Linux wrote:
> > So, if you want to use this, then you should update the CONFIG_BUG text
> > to include a warning to this effect:
> > 
> >      Warning: if CONFIG_BUG is turned off, and control flow reaches
> >      a BUG(), the system behaviour will be undefined.
> > 
> > so that people can make an informed choice about this, because at the
> > moment:
> > 
> >           Disabling this option eliminates support for BUG and WARN, reducing
> >           the size of your kernel image and potentially quietly ignoring
> >           numerous fatal conditions. You should only consider disabling this
> >           option for embedded systems with no facilities for reporting errors.
> >           Just say Y.
> > 
> > will become completely misleading.  Turning this option off will not
> > result in "quietly ignoring numerous fatal conditions".
> 
> I must be missing something, to me the two descriptions mean the same thing.

To me, the current text suggests that we still detect the fatal condition
but the code continues to execute in a manner controlled by the program.

The latter is uncontrolled code (or data) execution in ways unspecified
by the program.

> You don't just want to avoid the code for printing the bug message and
> the invalid instruction, we also want the compiler to not emit the 
> function call or check the enum for unexpected values. The meaning of
> BUG() is really that person writing that statement was sure it cannot
> happen unless there is a bug in the kernel, which has likely already
> corrupted data. Printing a diagnostic at this point is nice if someone
> is there to look at it, but letting the kernel do further actions that
> may be undefined is not going to make things worse.

I'm not talking about printing a diagnostic.  I'm talking about the CPU
remaining under the control of the program it is running - that being
the Linux kernel.

With CONFIG_BUG unset, turning on things like reboot-on-panic and such
like is worthless.  Arguably even is having a hardware watchdog - because
even if you hit one of these BUG() conditions where the CPU goes off and
does its own thing, it might be sufficient that the system is still able
to take care of the watchdog.

This is the problem you guys are missing - unreachable() means "we lose
control of the CPU at this point".

If you have an embedded system and you've taken out all the printk()
stuff, you most certainly want the system to do _something_ if you hit
an unexpected condition.

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Russell King - ARM Linux]

On Thu, May 23, 2013 at 12:59:43PM +0200, Arnd Bergmann wrote:
> On Thursday 23 May 2013, Russell King - ARM Linux wrote:
> > So, if you want to use this, then you should update the CONFIG_BUG text
> > to include a warning to this effect:
> > 
> >      Warning: if CONFIG_BUG is turned off, and control flow reaches
> >      a BUG(), the system behaviour will be undefined.
> > 
> > so that people can make an informed choice about this, because at the
> > moment:
> > 
> >           Disabling this option eliminates support for BUG and WARN, reducing
> >           the size of your kernel image and potentially quietly ignoring
> >           numerous fatal conditions. You should only consider disabling this
> >           option for embedded systems with no facilities for reporting errors.
> >           Just say Y.
> > 
> > will become completely misleading.  Turning this option off will not
> > result in "quietly ignoring numerous fatal conditions".
> 
> I must be missing something, to me the two descriptions mean the same thing.

To me, the current text suggests that we still detect the fatal condition
but the code continues to execute in a manner controlled by the program.

The latter is uncontrolled code (or data) execution in ways unspecified
by the program.

> You don't just want to avoid the code for printing the bug message and
> the invalid instruction, we also want the compiler to not emit the 
> function call or check the enum for unexpected values. The meaning of
> BUG() is really that person writing that statement was sure it cannot
> happen unless there is a bug in the kernel, which has likely already
> corrupted data. Printing a diagnostic at this point is nice if someone
> is there to look at it, but letting the kernel do further actions that
> may be undefined is not going to make things worse.

I'm not talking about printing a diagnostic.  I'm talking about the CPU
remaining under the control of the program it is running - that being
the Linux kernel.

With CONFIG_BUG unset, turning on things like reboot-on-panic and such
like is worthless.  Arguably even is having a hardware watchdog - because
even if you hit one of these BUG() conditions where the CPU goes off and
does its own thing, it might be sufficient that the system is still able
to take care of the watchdog.

This is the problem you guys are missing - unreachable() means "we lose
control of the CPU at this point".

If you have an embedded system and you've taken out all the printk()
stuff, you most certainly want the system to do _something_ if you hit
an unexpected condition.

[PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Russell King - ARM Linux]

On Thu, May 23, 2013 at 12:59:43PM +0200, Arnd Bergmann wrote:
> On Thursday 23 May 2013, Russell King - ARM Linux wrote:
> > So, if you want to use this, then you should update the CONFIG_BUG text
> > to include a warning to this effect:
> > 
> >      Warning: if CONFIG_BUG is turned off, and control flow reaches
> >      a BUG(), the system behaviour will be undefined.
> > 
> > so that people can make an informed choice about this, because at the
> > moment:
> > 
> >           Disabling this option eliminates support for BUG and WARN, reducing
> >           the size of your kernel image and potentially quietly ignoring
> >           numerous fatal conditions. You should only consider disabling this
> >           option for embedded systems with no facilities for reporting errors.
> >           Just say Y.
> > 
> > will become completely misleading.  Turning this option off will not
> > result in "quietly ignoring numerous fatal conditions".
> 
> I must be missing something, to me the two descriptions mean the same thing.

To me, the current text suggests that we still detect the fatal condition
but the code continues to execute in a manner controlled by the program.

The latter is uncontrolled code (or data) execution in ways unspecified
by the program.

> You don't just want to avoid the code for printing the bug message and
> the invalid instruction, we also want the compiler to not emit the 
> function call or check the enum for unexpected values. The meaning of
> BUG() is really that person writing that statement was sure it cannot
> happen unless there is a bug in the kernel, which has likely already
> corrupted data. Printing a diagnostic at this point is nice if someone
> is there to look at it, but letting the kernel do further actions that
> may be undefined is not going to make things worse.

I'm not talking about printing a diagnostic.  I'm talking about the CPU
remaining under the control of the program it is running - that being
the Linux kernel.

With CONFIG_BUG unset, turning on things like reboot-on-panic and such
like is worthless.  Arguably even is having a hardware watchdog - because
even if you hit one of these BUG() conditions where the CPU goes off and
does its own thing, it might be sufficient that the system is still able
to take care of the watchdog.

This is the problem you guys are missing - unreachable() means "we lose
control of the CPU at this point".

If you have an embedded system and you've taken out all the printk()
stuff, you most certainly want the system to do _something_ if you hit
an unexpected condition.

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Russell King - ARM Linux]

On Thu, May 23, 2013 at 12:59:43PM +0200, Arnd Bergmann wrote:
> On Thursday 23 May 2013, Russell King - ARM Linux wrote:
> > So, if you want to use this, then you should update the CONFIG_BUG text
> > to include a warning to this effect:
> > 
> >      Warning: if CONFIG_BUG is turned off, and control flow reaches
> >      a BUG(), the system behaviour will be undefined.
> > 
> > so that people can make an informed choice about this, because at the
> > moment:
> > 
> >           Disabling this option eliminates support for BUG and WARN, reducing
> >           the size of your kernel image and potentially quietly ignoring
> >           numerous fatal conditions. You should only consider disabling this
> >           option for embedded systems with no facilities for reporting errors.
> >           Just say Y.
> > 
> > will become completely misleading.  Turning this option off will not
> > result in "quietly ignoring numerous fatal conditions".
> 
> I must be missing something, to me the two descriptions mean the same thing.

To me, the current text suggests that we still detect the fatal condition
but the code continues to execute in a manner controlled by the program.

The latter is uncontrolled code (or data) execution in ways unspecified
by the program.

> You don't just want to avoid the code for printing the bug message and
> the invalid instruction, we also want the compiler to not emit the 
> function call or check the enum for unexpected values. The meaning of
> BUG() is really that person writing that statement was sure it cannot
> happen unless there is a bug in the kernel, which has likely already
> corrupted data. Printing a diagnostic at this point is nice if someone
> is there to look at it, but letting the kernel do further actions that
> may be undefined is not going to make things worse.

I'm not talking about printing a diagnostic.  I'm talking about the CPU
remaining under the control of the program it is running - that being
the Linux kernel.

With CONFIG_BUG unset, turning on things like reboot-on-panic and such
like is worthless.  Arguably even is having a hardware watchdog - because
even if you hit one of these BUG() conditions where the CPU goes off and
does its own thing, it might be sufficient that the system is still able
to take care of the watchdog.

This is the problem you guys are missing - unreachable() means "we lose
control of the CPU at this point".

If you have an embedded system and you've taken out all the printk()
stuff, you most certainly want the system to do _something_ if you hit
an unexpected condition.

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Arnd Bergmann]

On Thursday 23 May 2013, Russell King - ARM Linux wrote:
> This is the problem you guys are missing - unreachable() means "we lose
> control of the CPU at this point".

I'm absolutely aware of this. Again, the current behaviour of doing nothing
at all isn't very different from undefined behavior when you get when you
get to the end of a function returning a pointer without a "return" statement,
or when you return from a function that has determined that it is not safe
to continue.

> If you have an embedded system and you've taken out all the printk()
> stuff, you most certainly want the system to do something if you hit
> an unexpected condition.

I did not claim that it was a good idea to disable BUG(), all I said is
that "random stuff may happen" is probably what Matt Mackall had in mind when
he introduced the option.

	Arnd

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Arnd Bergmann]

On Thursday 23 May 2013, Russell King - ARM Linux wrote:
> This is the problem you guys are missing - unreachable() means "we lose
> control of the CPU at this point".

I'm absolutely aware of this. Again, the current behaviour of doing nothing
at all isn't very different from undefined behavior when you get when you
get to the end of a function returning a pointer without a "return" statement,
or when you return from a function that has determined that it is not safe
to continue.

> If you have an embedded system and you've taken out all the printk()
> stuff, you most certainly want the system to do something if you hit
> an unexpected condition.

I did not claim that it was a good idea to disable BUG(), all I said is
that "random stuff may happen" is probably what Matt Mackall had in mind when
he introduced the option.

	Arnd

[PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Arnd Bergmann]

On Thursday 23 May 2013, Russell King - ARM Linux wrote:
> This is the problem you guys are missing - unreachable() means "we lose
> control of the CPU at this point".

I'm absolutely aware of this. Again, the current behaviour of doing nothing
at all isn't very different from undefined behavior when you get when you
get to the end of a function returning a pointer without a "return" statement,
or when you return from a function that has determined that it is not safe
to continue.

> If you have an embedded system and you've taken out all the printk()
> stuff, you most certainly want the system to do something if you hit
> an unexpected condition.

I did not claim that it was a good idea to disable BUG(), all I said is
that "random stuff may happen" is probably what Matt Mackall had in mind when
he introduced the option.

	Arnd

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Arnd Bergmann]

On Thursday 23 May 2013, Russell King - ARM Linux wrote:
> This is the problem you guys are missing - unreachable() means "we lose
> control of the CPU at this point".

I'm absolutely aware of this. Again, the current behaviour of doing nothing
at all isn't very different from undefined behavior when you get when you
get to the end of a function returning a pointer without a "return" statement,
or when you return from a function that has determined that it is not safe
to continue.

> If you have an embedded system and you've taken out all the printk()
> stuff, you most certainly want the system to do something if you hit
> an unexpected condition.

I did not claim that it was a good idea to disable BUG(), all I said is
that "random stuff may happen" is probably what Matt Mackall had in mind when
he introduced the option.

	Arnd

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Russell King - ARM Linux]

On Thu, May 23, 2013 at 02:09:02PM +0200, Arnd Bergmann wrote:
> On Thursday 23 May 2013, Russell King - ARM Linux wrote:
> > This is the problem you guys are missing - unreachable() means "we lose
> > control of the CPU at this point".
> 
> I'm absolutely aware of this. Again, the current behaviour of doing nothing
> at all isn't very different from undefined behavior when you get when you
> get to the end of a function returning a pointer without a "return" statement,
> or when you return from a function that has determined that it is not safe
> to continue.

Running off the end of a function like that is a different kettle of fish.
The execution path is still as the compiler intends - what isn't is that
the data returned is likely to be random trash.

That's _quite_ different from the CPU starting to execute the contents
of a literal data pool.

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Russell King - ARM Linux]

On Thu, May 23, 2013 at 02:09:02PM +0200, Arnd Bergmann wrote:
> On Thursday 23 May 2013, Russell King - ARM Linux wrote:
> > This is the problem you guys are missing - unreachable() means "we lose
> > control of the CPU at this point".
> 
> I'm absolutely aware of this. Again, the current behaviour of doing nothing
> at all isn't very different from undefined behavior when you get when you
> get to the end of a function returning a pointer without a "return" statement,
> or when you return from a function that has determined that it is not safe
> to continue.

Running off the end of a function like that is a different kettle of fish.
The execution path is still as the compiler intends - what isn't is that
the data returned is likely to be random trash.

That's _quite_ different from the CPU starting to execute the contents
of a literal data pool.

[PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Russell King - ARM Linux]

On Thu, May 23, 2013 at 02:09:02PM +0200, Arnd Bergmann wrote:
> On Thursday 23 May 2013, Russell King - ARM Linux wrote:
> > This is the problem you guys are missing - unreachable() means "we lose
> > control of the CPU at this point".
> 
> I'm absolutely aware of this. Again, the current behaviour of doing nothing
> at all isn't very different from undefined behavior when you get when you
> get to the end of a function returning a pointer without a "return" statement,
> or when you return from a function that has determined that it is not safe
> to continue.

Running off the end of a function like that is a different kettle of fish.
The execution path is still as the compiler intends - what isn't is that
the data returned is likely to be random trash.

That's _quite_ different from the CPU starting to execute the contents
of a literal data pool.

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Russell King - ARM Linux]

On Thu, May 23, 2013 at 02:09:02PM +0200, Arnd Bergmann wrote:
> On Thursday 23 May 2013, Russell King - ARM Linux wrote:
> > This is the problem you guys are missing - unreachable() means "we lose
> > control of the CPU at this point".
> 
> I'm absolutely aware of this. Again, the current behaviour of doing nothing
> at all isn't very different from undefined behavior when you get when you
> get to the end of a function returning a pointer without a "return" statement,
> or when you return from a function that has determined that it is not safe
> to continue.

Running off the end of a function like that is a different kettle of fish.
The execution path is still as the compiler intends - what isn't is that
the data returned is likely to be random trash.

That's _quite_ different from the CPU starting to execute the contents
of a literal data pool.

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Geert Uytterhoeven]

On Thu, May 23, 2013 at 2:50 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Thu, May 23, 2013 at 02:09:02PM +0200, Arnd Bergmann wrote:
>> On Thursday 23 May 2013, Russell King - ARM Linux wrote:
>> > This is the problem you guys are missing - unreachable() means "we lose
>> > control of the CPU at this point".
>>
>> I'm absolutely aware of this. Again, the current behaviour of doing nothing
>> at all isn't very different from undefined behavior when you get when you
>> get to the end of a function returning a pointer without a "return" statement,
>> or when you return from a function that has determined that it is not safe
>> to continue.
>
> Running off the end of a function like that is a different kettle of fish.
> The execution path is still as the compiler intends - what isn't is that
> the data returned is likely to be random trash.
>
> That's _quite_ different from the CPU starting to execute the contents
> of a literal data pool.

I agree it's best to e.g. trap and reboot.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Geert Uytterhoeven]

On Thu, May 23, 2013 at 2:50 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Thu, May 23, 2013 at 02:09:02PM +0200, Arnd Bergmann wrote:
>> On Thursday 23 May 2013, Russell King - ARM Linux wrote:
>> > This is the problem you guys are missing - unreachable() means "we lose
>> > control of the CPU at this point".
>>
>> I'm absolutely aware of this. Again, the current behaviour of doing nothing
>> at all isn't very different from undefined behavior when you get when you
>> get to the end of a function returning a pointer without a "return" statement,
>> or when you return from a function that has determined that it is not safe
>> to continue.
>
> Running off the end of a function like that is a different kettle of fish.
> The execution path is still as the compiler intends - what isn't is that
> the data returned is likely to be random trash.
>
> That's _quite_ different from the CPU starting to execute the contents
> of a literal data pool.

I agree it's best to e.g. trap and reboot.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Geert Uytterhoeven]

On Thu, May 23, 2013 at 2:50 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Thu, May 23, 2013 at 02:09:02PM +0200, Arnd Bergmann wrote:
>> On Thursday 23 May 2013, Russell King - ARM Linux wrote:
>> > This is the problem you guys are missing - unreachable() means "we lose
>> > control of the CPU at this point".
>>
>> I'm absolutely aware of this. Again, the current behaviour of doing nothing
>> at all isn't very different from undefined behavior when you get when you
>> get to the end of a function returning a pointer without a "return" statement,
>> or when you return from a function that has determined that it is not safe
>> to continue.
>
> Running off the end of a function like that is a different kettle of fish.
> The execution path is still as the compiler intends - what isn't is that
> the data returned is likely to be random trash.
>
> That's _quite_ different from the CPU starting to execute the contents
> of a literal data pool.

I agree it's best to e.g. trap and reboot.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Geert Uytterhoeven]

On Thu, May 23, 2013 at 2:50 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Thu, May 23, 2013 at 02:09:02PM +0200, Arnd Bergmann wrote:
>> On Thursday 23 May 2013, Russell King - ARM Linux wrote:
>> > This is the problem you guys are missing - unreachable() means "we lose
>> > control of the CPU at this point".
>>
>> I'm absolutely aware of this. Again, the current behaviour of doing nothing
>> at all isn't very different from undefined behavior when you get when you
>> get to the end of a function returning a pointer without a "return" statement,
>> or when you return from a function that has determined that it is not safe
>> to continue.
>
> Running off the end of a function like that is a different kettle of fish.
> The execution path is still as the compiler intends - what isn't is that
> the data returned is likely to be random trash.
>
> That's _quite_ different from the CPU starting to execute the contents
> of a literal data pool.

I agree it's best to e.g. trap and reboot.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Chen Gang]

On 05/23/2013 10:10 PM, Geert Uytterhoeven wrote:
> On Thu, May 23, 2013 at 2:50 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
>> > On Thu, May 23, 2013 at 02:09:02PM +0200, Arnd Bergmann wrote:
>>> >> On Thursday 23 May 2013, Russell King - ARM Linux wrote:
>>>> >> > This is the problem you guys are missing - unreachable() means "we lose
>>>> >> > control of the CPU at this point".
>>> >>
>>> >> I'm absolutely aware of this. Again, the current behaviour of doing nothing
>>> >> at all isn't very different from undefined behavior when you get when you
>>> >> get to the end of a function returning a pointer without a "return" statement,
>>> >> or when you return from a function that has determined that it is not safe
>>> >> to continue.
>> >
>> > Running off the end of a function like that is a different kettle of fish.
>> > The execution path is still as the compiler intends - what isn't is that
>> > the data returned is likely to be random trash.
>> >
>> > That's _quite_ different from the CPU starting to execute the contents
>> > of a literal data pool.
> I agree it's best to e.g. trap and reboot.

After read the arch/*/include/asm/bug.h,

It seems panic() is not suitable for NOMMU platforms (only m68k use it,
also need CONFIG_BUG and CONFIG_SUN3 enabled).

And unreachable() is need followed with an asm inline instruction (arm,
x86, powerpc mips...).

And __builtin_trap() is "the mechanism used may vary from release to
release so should not rely on any particular implementation" (ref to
"http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html", used by m68k,
sparc, ia64).

I can not find any *trap*() and *unreachable*() in "include/asm-generic/"

I can not find any suitable implementation which 'generic' enough to add
in "include/asm-generic/" (and in fact, CONFIG_BUG itself is not
'generic' enough to be in "include/asm-generic/").


At last, I still suggest to delete CONFIG_BUG, so most of architectures
can skip this issue firstly.

Then for specific architectures, also can get 3 benefits:

a. the related maintainers can implement it as their own willing (not
need discus it with another platform maintainers again);

b. the related maintainers can free use the platform specific features
(which can not be used in "include/asm-generic/");

c. the related maintainers are more familiar their own architectures
demands and requirements.



----------- arch/m68k/include/asm/bug.h --------------------------------

  1 #ifndef _M68K_BUG_H
  2 #define _M68K_BUG_H
  3
  4 #ifdef CONFIG_MMU
  5 #ifdef CONFIG_BUG
  6 #ifdef CONFIG_DEBUG_BUGVERBOSE
  7 #ifndef CONFIG_SUN3
  8 #define BUG() do { \
  9         printk("kernel BUG at %s:%d!\n", __FILE__, __LINE__); \
 10         __builtin_trap(); \
 11 } while (0)
 12 #else
 13 #define BUG() do { \
 14         printk("kernel BUG at %s:%d!\n", __FILE__, __LINE__); \
 15         panic("BUG!"); \
 16 } while (0)
 17 #endif
 18 #else
 19 #define BUG() do { \
 20         __builtin_trap(); \
 21 } while (0)
 22 #endif
 23
 24 #define HAVE_ARCH_BUG
 25 #endif
 26 #endif /* CONFIG_MMU */
 27
 28 #include <asm-generic/bug.h>
 29
 30 #endif




Thanks.
-- 
Chen Gang

Asianux Corporation

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Chen Gang]

On 05/23/2013 10:10 PM, Geert Uytterhoeven wrote:
> On Thu, May 23, 2013 at 2:50 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
>> > On Thu, May 23, 2013 at 02:09:02PM +0200, Arnd Bergmann wrote:
>>> >> On Thursday 23 May 2013, Russell King - ARM Linux wrote:
>>>> >> > This is the problem you guys are missing - unreachable() means "we lose
>>>> >> > control of the CPU at this point".
>>> >>
>>> >> I'm absolutely aware of this. Again, the current behaviour of doing nothing
>>> >> at all isn't very different from undefined behavior when you get when you
>>> >> get to the end of a function returning a pointer without a "return" statement,
>>> >> or when you return from a function that has determined that it is not safe
>>> >> to continue.
>> >
>> > Running off the end of a function like that is a different kettle of fish.
>> > The execution path is still as the compiler intends - what isn't is that
>> > the data returned is likely to be random trash.
>> >
>> > That's _quite_ different from the CPU starting to execute the contents
>> > of a literal data pool.
> I agree it's best to e.g. trap and reboot.

After read the arch/*/include/asm/bug.h,

It seems panic() is not suitable for NOMMU platforms (only m68k use it,
also need CONFIG_BUG and CONFIG_SUN3 enabled).

And unreachable() is need followed with an asm inline instruction (arm,
x86, powerpc mips...).

And __builtin_trap() is "the mechanism used may vary from release to
release so should not rely on any particular implementation" (ref to
"http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html", used by m68k,
sparc, ia64).

I can not find any *trap*() and *unreachable*() in "include/asm-generic/"

I can not find any suitable implementation which 'generic' enough to add
in "include/asm-generic/" (and in fact, CONFIG_BUG itself is not
'generic' enough to be in "include/asm-generic/").


At last, I still suggest to delete CONFIG_BUG, so most of architectures
can skip this issue firstly.

Then for specific architectures, also can get 3 benefits:

a. the related maintainers can implement it as their own willing (not
need discus it with another platform maintainers again);

b. the related maintainers can free use the platform specific features
(which can not be used in "include/asm-generic/");

c. the related maintainers are more familiar their own architectures
demands and requirements.



----------- arch/m68k/include/asm/bug.h --------------------------------

  1 #ifndef _M68K_BUG_H
  2 #define _M68K_BUG_H
  3
  4 #ifdef CONFIG_MMU
  5 #ifdef CONFIG_BUG
  6 #ifdef CONFIG_DEBUG_BUGVERBOSE
  7 #ifndef CONFIG_SUN3
  8 #define BUG() do { \
  9         printk("kernel BUG at %s:%d!\n", __FILE__, __LINE__); \
 10         __builtin_trap(); \
 11 } while (0)
 12 #else
 13 #define BUG() do { \
 14         printk("kernel BUG at %s:%d!\n", __FILE__, __LINE__); \
 15         panic("BUG!"); \
 16 } while (0)
 17 #endif
 18 #else
 19 #define BUG() do { \
 20         __builtin_trap(); \
 21 } while (0)
 22 #endif
 23
 24 #define HAVE_ARCH_BUG
 25 #endif
 26 #endif /* CONFIG_MMU */
 27
 28 #include <asm-generic/bug.h>
 29
 30 #endif




Thanks.
-- 
Chen Gang

Asianux Corporation

[PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Chen Gang]

On 05/23/2013 10:10 PM, Geert Uytterhoeven wrote:
> On Thu, May 23, 2013 at 2:50 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
>> > On Thu, May 23, 2013 at 02:09:02PM +0200, Arnd Bergmann wrote:
>>> >> On Thursday 23 May 2013, Russell King - ARM Linux wrote:
>>>> >> > This is the problem you guys are missing - unreachable() means "we lose
>>>> >> > control of the CPU at this point".
>>> >>
>>> >> I'm absolutely aware of this. Again, the current behaviour of doing nothing
>>> >> at all isn't very different from undefined behavior when you get when you
>>> >> get to the end of a function returning a pointer without a "return" statement,
>>> >> or when you return from a function that has determined that it is not safe
>>> >> to continue.
>> >
>> > Running off the end of a function like that is a different kettle of fish.
>> > The execution path is still as the compiler intends - what isn't is that
>> > the data returned is likely to be random trash.
>> >
>> > That's _quite_ different from the CPU starting to execute the contents
>> > of a literal data pool.
> I agree it's best to e.g. trap and reboot.

After read the arch/*/include/asm/bug.h,

It seems panic() is not suitable for NOMMU platforms (only m68k use it,
also need CONFIG_BUG and CONFIG_SUN3 enabled).

And unreachable() is need followed with an asm inline instruction (arm,
x86, powerpc mips...).

And __builtin_trap() is "the mechanism used may vary from release to
release so should not rely on any particular implementation" (ref to
"http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html", used by m68k,
sparc, ia64).

I can not find any *trap*() and *unreachable*() in "include/asm-generic/"

I can not find any suitable implementation which 'generic' enough to add
in "include/asm-generic/" (and in fact, CONFIG_BUG itself is not
'generic' enough to be in "include/asm-generic/").


At last, I still suggest to delete CONFIG_BUG, so most of architectures
can skip this issue firstly.

Then for specific architectures, also can get 3 benefits:

a. the related maintainers can implement it as their own willing (not
need discus it with another platform maintainers again);

b. the related maintainers can free use the platform specific features
(which can not be used in "include/asm-generic/");

c. the related maintainers are more familiar their own architectures
demands and requirements.



----------- arch/m68k/include/asm/bug.h --------------------------------

  1 #ifndef _M68K_BUG_H
  2 #define _M68K_BUG_H
  3
  4 #ifdef CONFIG_MMU
  5 #ifdef CONFIG_BUG
  6 #ifdef CONFIG_DEBUG_BUGVERBOSE
  7 #ifndef CONFIG_SUN3
  8 #define BUG() do { \
  9         printk("kernel BUG at %s:%d!\n", __FILE__, __LINE__); \
 10         __builtin_trap(); \
 11 } while (0)
 12 #else
 13 #define BUG() do { \
 14         printk("kernel BUG at %s:%d!\n", __FILE__, __LINE__); \
 15         panic("BUG!"); \
 16 } while (0)
 17 #endif
 18 #else
 19 #define BUG() do { \
 20         __builtin_trap(); \
 21 } while (0)
 22 #endif
 23
 24 #define HAVE_ARCH_BUG
 25 #endif
 26 #endif /* CONFIG_MMU */
 27
 28 #include <asm-generic/bug.h>
 29
 30 #endif




Thanks.
-- 
Chen Gang

Asianux Corporation

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Chen Gang]

On 05/23/2013 10:10 PM, Geert Uytterhoeven wrote:
> On Thu, May 23, 2013 at 2:50 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
>> > On Thu, May 23, 2013 at 02:09:02PM +0200, Arnd Bergmann wrote:
>>> >> On Thursday 23 May 2013, Russell King - ARM Linux wrote:
>>>> >> > This is the problem you guys are missing - unreachable() means "we lose
>>>> >> > control of the CPU at this point".
>>> >>
>>> >> I'm absolutely aware of this. Again, the current behaviour of doing nothing
>>> >> at all isn't very different from undefined behavior when you get when you
>>> >> get to the end of a function returning a pointer without a "return" statement,
>>> >> or when you return from a function that has determined that it is not safe
>>> >> to continue.
>> >
>> > Running off the end of a function like that is a different kettle of fish.
>> > The execution path is still as the compiler intends - what isn't is that
>> > the data returned is likely to be random trash.
>> >
>> > That's _quite_ different from the CPU starting to execute the contents
>> > of a literal data pool.
> I agree it's best to e.g. trap and reboot.

After read the arch/*/include/asm/bug.h,

It seems panic() is not suitable for NOMMU platforms (only m68k use it,
also need CONFIG_BUG and CONFIG_SUN3 enabled).

And unreachable() is need followed with an asm inline instruction (arm,
x86, powerpc mips...).

And __builtin_trap() is "the mechanism used may vary from release to
release so should not rely on any particular implementation" (ref to
"http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html", used by m68k,
sparc, ia64).

I can not find any *trap*() and *unreachable*() in "include/asm-generic/"

I can not find any suitable implementation which 'generic' enough to add
in "include/asm-generic/" (and in fact, CONFIG_BUG itself is not
'generic' enough to be in "include/asm-generic/").


At last, I still suggest to delete CONFIG_BUG, so most of architectures
can skip this issue firstly.

Then for specific architectures, also can get 3 benefits:

a. the related maintainers can implement it as their own willing (not
need discus it with another platform maintainers again);

b. the related maintainers can free use the platform specific features
(which can not be used in "include/asm-generic/");

c. the related maintainers are more familiar their own architectures
demands and requirements.



----------- arch/m68k/include/asm/bug.h --------------------------------

  1 #ifndef _M68K_BUG_H
  2 #define _M68K_BUG_H
  3
  4 #ifdef CONFIG_MMU
  5 #ifdef CONFIG_BUG
  6 #ifdef CONFIG_DEBUG_BUGVERBOSE
  7 #ifndef CONFIG_SUN3
  8 #define BUG() do { \
  9         printk("kernel BUG at %s:%d!\n", __FILE__, __LINE__); \
 10         __builtin_trap(); \
 11 } while (0)
 12 #else
 13 #define BUG() do { \
 14         printk("kernel BUG at %s:%d!\n", __FILE__, __LINE__); \
 15         panic("BUG!"); \
 16 } while (0)
 17 #endif
 18 #else
 19 #define BUG() do { \
 20         __builtin_trap(); \
 21 } while (0)
 22 #endif
 23
 24 #define HAVE_ARCH_BUG
 25 #endif
 26 #endif /* CONFIG_MMU */
 27
 28 #include <asm-generic/bug.h>
 29
 30 #endif




Thanks.
-- 
Chen Gang

Asianux Corporation
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Chen Gang]

On 05/24/2013 10:13 AM, Chen Gang wrote:
> On 05/23/2013 10:10 PM, Geert Uytterhoeven wrote:
>> On Thu, May 23, 2013 at 2:50 PM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>>>> On Thu, May 23, 2013 at 02:09:02PM +0200, Arnd Bergmann wrote:
>>>>>> On Thursday 23 May 2013, Russell King - ARM Linux wrote:
>>>>>>>> This is the problem you guys are missing - unreachable() means "we lose
>>>>>>>> control of the CPU at this point".
>>>>>>
>>>>>> I'm absolutely aware of this. Again, the current behaviour of doing nothing
>>>>>> at all isn't very different from undefined behavior when you get when you
>>>>>> get to the end of a function returning a pointer without a "return" statement,
>>>>>> or when you return from a function that has determined that it is not safe
>>>>>> to continue.
>>>>
>>>> Running off the end of a function like that is a different kettle of fish.
>>>> The execution path is still as the compiler intends - what isn't is that
>>>> the data returned is likely to be random trash.
>>>>
>>>> That's _quite_ different from the CPU starting to execute the contents
>>>> of a literal data pool.
>> I agree it's best to e.g. trap and reboot.
> 

In fact: if enable CONFIG_BUG, but not enable HAVE_ARCH_BUG, the
default implementation is:

 47 #ifndef HAVE_ARCH_BUG
 48 #define BUG() do { \
 49         printk("BUG: failure at %s:%d/%s()!\n", __FILE__, __LINE__, __func__); \
 50         panic("BUG!"); \
 51 } while (0)
 52 #endif

So if we delete CONFIG_BUG, the default implementation will be almost
like panic(),  and in panic() itself, also calls printk() !!

So...

:-)



> After read the arch/*/include/asm/bug.h,
> 
> It seems panic() is not suitable for NOMMU platforms (only m68k use it,
> also need CONFIG_BUG and CONFIG_SUN3 enabled).
> 
> And unreachable() is need followed with an asm inline instruction (arm,
> x86, powerpc mips...).
> 
> And __builtin_trap() is "the mechanism used may vary from release to
> release so should not rely on any particular implementation" (ref to
> "http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html", used by m68k,
> sparc, ia64).
> 
> I can not find any *trap*() and *unreachable*() in "include/asm-generic/"
> 
> I can not find any suitable implementation which 'generic' enough to add
> in "include/asm-generic/" (and in fact, CONFIG_BUG itself is not
> 'generic' enough to be in "include/asm-generic/").
> 
> 
> At last, I still suggest to delete CONFIG_BUG, so most of architectures
> can skip this issue firstly.
> 
> Then for specific architectures, also can get 3 benefits:
> 
> a. the related maintainers can implement it as their own willing (not
> need discus it with another platform maintainers again);
> 
> b. the related maintainers can free use the platform specific features
> (which can not be used in "include/asm-generic/");
> 
> c. the related maintainers are more familiar their own architectures
> demands and requirements.
> 
> 
> 
> ----------- arch/m68k/include/asm/bug.h --------------------------------
> 
>   1 #ifndef _M68K_BUG_H
>   2 #define _M68K_BUG_H
>   3
>   4 #ifdef CONFIG_MMU
>   5 #ifdef CONFIG_BUG
>   6 #ifdef CONFIG_DEBUG_BUGVERBOSE
>   7 #ifndef CONFIG_SUN3
>   8 #define BUG() do { \
>   9         printk("kernel BUG at %s:%d!\n", __FILE__, __LINE__); \
>  10         __builtin_trap(); \
>  11 } while (0)
>  12 #else
>  13 #define BUG() do { \
>  14         printk("kernel BUG at %s:%d!\n", __FILE__, __LINE__); \
>  15         panic("BUG!"); \
>  16 } while (0)
>  17 #endif
>  18 #else
>  19 #define BUG() do { \
>  20         __builtin_trap(); \
>  21 } while (0)
>  22 #endif
>  23
>  24 #define HAVE_ARCH_BUG
>  25 #endif
>  26 #endif /* CONFIG_MMU */
>  27
>  28 #include <asm-generic/bug.h>
>  29
>  30 #endif
> 
> 
> 
> 
> Thanks.
> 


-- 
Chen Gang

Asianux Corporation

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Chen Gang]

On 05/24/2013 10:13 AM, Chen Gang wrote:
> On 05/23/2013 10:10 PM, Geert Uytterhoeven wrote:
>> On Thu, May 23, 2013 at 2:50 PM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>>>> On Thu, May 23, 2013 at 02:09:02PM +0200, Arnd Bergmann wrote:
>>>>>> On Thursday 23 May 2013, Russell King - ARM Linux wrote:
>>>>>>>> This is the problem you guys are missing - unreachable() means "we lose
>>>>>>>> control of the CPU at this point".
>>>>>>
>>>>>> I'm absolutely aware of this. Again, the current behaviour of doing nothing
>>>>>> at all isn't very different from undefined behavior when you get when you
>>>>>> get to the end of a function returning a pointer without a "return" statement,
>>>>>> or when you return from a function that has determined that it is not safe
>>>>>> to continue.
>>>>
>>>> Running off the end of a function like that is a different kettle of fish.
>>>> The execution path is still as the compiler intends - what isn't is that
>>>> the data returned is likely to be random trash.
>>>>
>>>> That's _quite_ different from the CPU starting to execute the contents
>>>> of a literal data pool.
>> I agree it's best to e.g. trap and reboot.
> 

In fact: if enable CONFIG_BUG, but not enable HAVE_ARCH_BUG, the
default implementation is:

 47 #ifndef HAVE_ARCH_BUG
 48 #define BUG() do { \
 49         printk("BUG: failure at %s:%d/%s()!\n", __FILE__, __LINE__, __func__); \
 50         panic("BUG!"); \
 51 } while (0)
 52 #endif

So if we delete CONFIG_BUG, the default implementation will be almost
like panic(),  and in panic() itself, also calls printk() !!

So...

:-)



> After read the arch/*/include/asm/bug.h,
> 
> It seems panic() is not suitable for NOMMU platforms (only m68k use it,
> also need CONFIG_BUG and CONFIG_SUN3 enabled).
> 
> And unreachable() is need followed with an asm inline instruction (arm,
> x86, powerpc mips...).
> 
> And __builtin_trap() is "the mechanism used may vary from release to
> release so should not rely on any particular implementation" (ref to
> "http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html", used by m68k,
> sparc, ia64).
> 
> I can not find any *trap*() and *unreachable*() in "include/asm-generic/"
> 
> I can not find any suitable implementation which 'generic' enough to add
> in "include/asm-generic/" (and in fact, CONFIG_BUG itself is not
> 'generic' enough to be in "include/asm-generic/").
> 
> 
> At last, I still suggest to delete CONFIG_BUG, so most of architectures
> can skip this issue firstly.
> 
> Then for specific architectures, also can get 3 benefits:
> 
> a. the related maintainers can implement it as their own willing (not
> need discus it with another platform maintainers again);
> 
> b. the related maintainers can free use the platform specific features
> (which can not be used in "include/asm-generic/");
> 
> c. the related maintainers are more familiar their own architectures
> demands and requirements.
> 
> 
> 
> ----------- arch/m68k/include/asm/bug.h --------------------------------
> 
>   1 #ifndef _M68K_BUG_H
>   2 #define _M68K_BUG_H
>   3
>   4 #ifdef CONFIG_MMU
>   5 #ifdef CONFIG_BUG
>   6 #ifdef CONFIG_DEBUG_BUGVERBOSE
>   7 #ifndef CONFIG_SUN3
>   8 #define BUG() do { \
>   9         printk("kernel BUG at %s:%d!\n", __FILE__, __LINE__); \
>  10         __builtin_trap(); \
>  11 } while (0)
>  12 #else
>  13 #define BUG() do { \
>  14         printk("kernel BUG at %s:%d!\n", __FILE__, __LINE__); \
>  15         panic("BUG!"); \
>  16 } while (0)
>  17 #endif
>  18 #else
>  19 #define BUG() do { \
>  20         __builtin_trap(); \
>  21 } while (0)
>  22 #endif
>  23
>  24 #define HAVE_ARCH_BUG
>  25 #endif
>  26 #endif /* CONFIG_MMU */
>  27
>  28 #include <asm-generic/bug.h>
>  29
>  30 #endif
> 
> 
> 
> 
> Thanks.
> 


-- 
Chen Gang

Asianux Corporation

[PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Chen Gang]

On 05/24/2013 10:13 AM, Chen Gang wrote:
> On 05/23/2013 10:10 PM, Geert Uytterhoeven wrote:
>> On Thu, May 23, 2013 at 2:50 PM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>>>> On Thu, May 23, 2013 at 02:09:02PM +0200, Arnd Bergmann wrote:
>>>>>> On Thursday 23 May 2013, Russell King - ARM Linux wrote:
>>>>>>>> This is the problem you guys are missing - unreachable() means "we lose
>>>>>>>> control of the CPU at this point".
>>>>>>
>>>>>> I'm absolutely aware of this. Again, the current behaviour of doing nothing
>>>>>> at all isn't very different from undefined behavior when you get when you
>>>>>> get to the end of a function returning a pointer without a "return" statement,
>>>>>> or when you return from a function that has determined that it is not safe
>>>>>> to continue.
>>>>
>>>> Running off the end of a function like that is a different kettle of fish.
>>>> The execution path is still as the compiler intends - what isn't is that
>>>> the data returned is likely to be random trash.
>>>>
>>>> That's _quite_ different from the CPU starting to execute the contents
>>>> of a literal data pool.
>> I agree it's best to e.g. trap and reboot.
> 

In fact: if enable CONFIG_BUG, but not enable HAVE_ARCH_BUG, the
default implementation is:

 47 #ifndef HAVE_ARCH_BUG
 48 #define BUG() do { \
 49         printk("BUG: failure at %s:%d/%s()!\n", __FILE__, __LINE__, __func__); \
 50         panic("BUG!"); \
 51 } while (0)
 52 #endif

So if we delete CONFIG_BUG, the default implementation will be almost
like panic(),  and in panic() itself, also calls printk() !!

So...

:-)



> After read the arch/*/include/asm/bug.h,
> 
> It seems panic() is not suitable for NOMMU platforms (only m68k use it,
> also need CONFIG_BUG and CONFIG_SUN3 enabled).
> 
> And unreachable() is need followed with an asm inline instruction (arm,
> x86, powerpc mips...).
> 
> And __builtin_trap() is "the mechanism used may vary from release to
> release so should not rely on any particular implementation" (ref to
> "http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html", used by m68k,
> sparc, ia64).
> 
> I can not find any *trap*() and *unreachable*() in "include/asm-generic/"
> 
> I can not find any suitable implementation which 'generic' enough to add
> in "include/asm-generic/" (and in fact, CONFIG_BUG itself is not
> 'generic' enough to be in "include/asm-generic/").
> 
> 
> At last, I still suggest to delete CONFIG_BUG, so most of architectures
> can skip this issue firstly.
> 
> Then for specific architectures, also can get 3 benefits:
> 
> a. the related maintainers can implement it as their own willing (not
> need discus it with another platform maintainers again);
> 
> b. the related maintainers can free use the platform specific features
> (which can not be used in "include/asm-generic/");
> 
> c. the related maintainers are more familiar their own architectures
> demands and requirements.
> 
> 
> 
> ----------- arch/m68k/include/asm/bug.h --------------------------------
> 
>   1 #ifndef _M68K_BUG_H
>   2 #define _M68K_BUG_H
>   3
>   4 #ifdef CONFIG_MMU
>   5 #ifdef CONFIG_BUG
>   6 #ifdef CONFIG_DEBUG_BUGVERBOSE
>   7 #ifndef CONFIG_SUN3
>   8 #define BUG() do { \
>   9         printk("kernel BUG at %s:%d!\n", __FILE__, __LINE__); \
>  10         __builtin_trap(); \
>  11 } while (0)
>  12 #else
>  13 #define BUG() do { \
>  14         printk("kernel BUG at %s:%d!\n", __FILE__, __LINE__); \
>  15         panic("BUG!"); \
>  16 } while (0)
>  17 #endif
>  18 #else
>  19 #define BUG() do { \
>  20         __builtin_trap(); \
>  21 } while (0)
>  22 #endif
>  23
>  24 #define HAVE_ARCH_BUG
>  25 #endif
>  26 #endif /* CONFIG_MMU */
>  27
>  28 #include <asm-generic/bug.h>
>  29
>  30 #endif
> 
> 
> 
> 
> Thanks.
> 


-- 
Chen Gang

Asianux Corporation

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Chen Gang]

On 05/24/2013 10:13 AM, Chen Gang wrote:
> On 05/23/2013 10:10 PM, Geert Uytterhoeven wrote:
>> On Thu, May 23, 2013 at 2:50 PM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>>>> On Thu, May 23, 2013 at 02:09:02PM +0200, Arnd Bergmann wrote:
>>>>>> On Thursday 23 May 2013, Russell King - ARM Linux wrote:
>>>>>>>> This is the problem you guys are missing - unreachable() means "we lose
>>>>>>>> control of the CPU at this point".
>>>>>>
>>>>>> I'm absolutely aware of this. Again, the current behaviour of doing nothing
>>>>>> at all isn't very different from undefined behavior when you get when you
>>>>>> get to the end of a function returning a pointer without a "return" statement,
>>>>>> or when you return from a function that has determined that it is not safe
>>>>>> to continue.
>>>>
>>>> Running off the end of a function like that is a different kettle of fish.
>>>> The execution path is still as the compiler intends - what isn't is that
>>>> the data returned is likely to be random trash.
>>>>
>>>> That's _quite_ different from the CPU starting to execute the contents
>>>> of a literal data pool.
>> I agree it's best to e.g. trap and reboot.
> 

In fact: if enable CONFIG_BUG, but not enable HAVE_ARCH_BUG, the
default implementation is:

 47 #ifndef HAVE_ARCH_BUG
 48 #define BUG() do { \
 49         printk("BUG: failure at %s:%d/%s()!\n", __FILE__, __LINE__, __func__); \
 50         panic("BUG!"); \
 51 } while (0)
 52 #endif

So if we delete CONFIG_BUG, the default implementation will be almost
like panic(),  and in panic() itself, also calls printk() !!

So...

:-)



> After read the arch/*/include/asm/bug.h,
> 
> It seems panic() is not suitable for NOMMU platforms (only m68k use it,
> also need CONFIG_BUG and CONFIG_SUN3 enabled).
> 
> And unreachable() is need followed with an asm inline instruction (arm,
> x86, powerpc mips...).
> 
> And __builtin_trap() is "the mechanism used may vary from release to
> release so should not rely on any particular implementation" (ref to
> "http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html", used by m68k,
> sparc, ia64).
> 
> I can not find any *trap*() and *unreachable*() in "include/asm-generic/"
> 
> I can not find any suitable implementation which 'generic' enough to add
> in "include/asm-generic/" (and in fact, CONFIG_BUG itself is not
> 'generic' enough to be in "include/asm-generic/").
> 
> 
> At last, I still suggest to delete CONFIG_BUG, so most of architectures
> can skip this issue firstly.
> 
> Then for specific architectures, also can get 3 benefits:
> 
> a. the related maintainers can implement it as their own willing (not
> need discus it with another platform maintainers again);
> 
> b. the related maintainers can free use the platform specific features
> (which can not be used in "include/asm-generic/");
> 
> c. the related maintainers are more familiar their own architectures
> demands and requirements.
> 
> 
> 
> ----------- arch/m68k/include/asm/bug.h --------------------------------
> 
>   1 #ifndef _M68K_BUG_H
>   2 #define _M68K_BUG_H
>   3
>   4 #ifdef CONFIG_MMU
>   5 #ifdef CONFIG_BUG
>   6 #ifdef CONFIG_DEBUG_BUGVERBOSE
>   7 #ifndef CONFIG_SUN3
>   8 #define BUG() do { \
>   9         printk("kernel BUG at %s:%d!\n", __FILE__, __LINE__); \
>  10         __builtin_trap(); \
>  11 } while (0)
>  12 #else
>  13 #define BUG() do { \
>  14         printk("kernel BUG at %s:%d!\n", __FILE__, __LINE__); \
>  15         panic("BUG!"); \
>  16 } while (0)
>  17 #endif
>  18 #else
>  19 #define BUG() do { \
>  20         __builtin_trap(); \
>  21 } while (0)
>  22 #endif
>  23
>  24 #define HAVE_ARCH_BUG
>  25 #endif
>  26 #endif /* CONFIG_MMU */
>  27
>  28 #include <asm-generic/bug.h>
>  29
>  30 #endif
> 
> 
> 
> 
> Thanks.
> 


-- 
Chen Gang

Asianux Corporation

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Eric W. Biederman]

Chen Gang <gang.chen@asianux.com> writes:

> The crazy user can unset 'CONFIG_BUG' in menuconfig: "> General setup >
> Configure standard kernel features (expert users) > BUG() Support".
>
> But in fact, we always need it, and quite a few of architectures have
> already implemented it (e.g. alpha, arc, arm, avr32, blackfin, cris,
> frv, ia64, m68k, mips, mn10300, parisc, powerpc, s390, sh, sparc, x86).
>
> And kernel also already has prepared a default effective implementation
> for the architectures which is unwilling to implement it by themselves
> (e.g. arm64, c6x, h8300, hexagon, m32r, metag, microblaze, openrisc,
> score, tile, um, unicore32, xtensa).
>
> So need get rid of 'CONFIG_BUG', and let it always enabled everywhere.


This looks like the right way to handle this to me.  If the BUG
annotations are too big and not needed they should simply be deleted
from the code base.  Disabling CONFIG_BUG which removes the BUG
annotations from the binaries without modifying the source code seems
like the wrong approach.

Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Eric W. Biederman]

Chen Gang <gang.chen@asianux.com> writes:

> The crazy user can unset 'CONFIG_BUG' in menuconfig: "> General setup >
> Configure standard kernel features (expert users) > BUG() Support".
>
> But in fact, we always need it, and quite a few of architectures have
> already implemented it (e.g. alpha, arc, arm, avr32, blackfin, cris,
> frv, ia64, m68k, mips, mn10300, parisc, powerpc, s390, sh, sparc, x86).
>
> And kernel also already has prepared a default effective implementation
> for the architectures which is unwilling to implement it by themselves
> (e.g. arm64, c6x, h8300, hexagon, m32r, metag, microblaze, openrisc,
> score, tile, um, unicore32, xtensa).
>
> So need get rid of 'CONFIG_BUG', and let it always enabled everywhere.


This looks like the right way to handle this to me.  If the BUG
annotations are too big and not needed they should simply be deleted
from the code base.  Disabling CONFIG_BUG which removes the BUG
annotations from the binaries without modifying the source code seems
like the wrong approach.

Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>

[PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Eric W. Biederman]

Chen Gang <gang.chen@asianux.com> writes:

> The crazy user can unset 'CONFIG_BUG' in menuconfig: "> General setup >
> Configure standard kernel features (expert users) > BUG() Support".
>
> But in fact, we always need it, and quite a few of architectures have
> already implemented it (e.g. alpha, arc, arm, avr32, blackfin, cris,
> frv, ia64, m68k, mips, mn10300, parisc, powerpc, s390, sh, sparc, x86).
>
> And kernel also already has prepared a default effective implementation
> for the architectures which is unwilling to implement it by themselves
> (e.g. arm64, c6x, h8300, hexagon, m32r, metag, microblaze, openrisc,
> score, tile, um, unicore32, xtensa).
>
> So need get rid of 'CONFIG_BUG', and let it always enabled everywhere.


This looks like the right way to handle this to me.  If the BUG
annotations are too big and not needed they should simply be deleted
from the code base.  Disabling CONFIG_BUG which removes the BUG
annotations from the binaries without modifying the source code seems
like the wrong approach.

Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Eric W. Biederman]

Chen Gang <gang.chen@asianux.com> writes:

> The crazy user can unset 'CONFIG_BUG' in menuconfig: "> General setup >
> Configure standard kernel features (expert users) > BUG() Support".
>
> But in fact, we always need it, and quite a few of architectures have
> already implemented it (e.g. alpha, arc, arm, avr32, blackfin, cris,
> frv, ia64, m68k, mips, mn10300, parisc, powerpc, s390, sh, sparc, x86).
>
> And kernel also already has prepared a default effective implementation
> for the architectures which is unwilling to implement it by themselves
> (e.g. arm64, c6x, h8300, hexagon, m32r, metag, microblaze, openrisc,
> score, tile, um, unicore32, xtensa).
>
> So need get rid of 'CONFIG_BUG', and let it always enabled everywhere.


This looks like the right way to handle this to me.  If the BUG
annotations are too big and not needed they should simply be deleted
from the code base.  Disabling CONFIG_BUG which removes the BUG
annotations from the binaries without modifying the source code seems
like the wrong approach.

Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>

[PATCH v2] arch: configuration issue, random return value when disable 'CONFIG_BUG'

[Chen Gang]

If user disable 'CONFIG_BUG' in menuconfig, many areas not only will
report compiling warnings, but also may return a random value from the
function when BUG().

In fact, most of architectures need always let 'CONFIG_BUG' enabled, so
'#ifdef CONFIG_BUG' is already not 'generic' enough in "include/asm-
generic/".

Also kernel has already provided the 'generic' implementation in
"include/asm-generic" when 'CONFIG_BUG' enabled. Even if we disable
'CONFIG_BUG', we also shall have to implement the BUG() in "include/asm-
generic", just like when 'CONFIG_BUG' enabled (at least, it is not the
minimal size implementation).

So need remove 'CONFIG_BUG', and let it always enabled everywhere, then
fix this issue.

The architectures which need their own architecture specific features
(e.g. minimal size implementation), can customize their own BUG() and
__WARN_TAINT() to give a better fix (e.g. use one inline asm code, then
followed by 'unreachable' function, or another more better fix ways).


Signed-off-by: Chen Gang <gang.chen@asianux.com>
---
 arch/arm/Kconfig          |    1 -
 arch/avr32/Kconfig        |    1 -
 arch/blackfin/Kconfig     |    1 -
 arch/h8300/Kconfig        |    1 -
 arch/hexagon/Kconfig      |    1 -
 arch/parisc/Kconfig       |    2 --
 arch/powerpc/Kconfig      |    1 -
 arch/s390/Kconfig         |    2 +-
 arch/sh/Kconfig           |    2 +-
 arch/um/Kconfig.common    |    1 -
 arch/x86/Kconfig          |    1 -
 include/asm-generic/bug.h |   29 -----------------------------
 init/Kconfig              |   10 ----------
 lib/Kconfig.debug         |    2 +-
 14 files changed, 3 insertions(+), 52 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index a7fc5ea..ea4a146 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -265,7 +265,6 @@ config PHYS_OFFSET
 
 config GENERIC_BUG
 	def_bool y
-	depends on BUG
 
 source "init/Kconfig"
 
diff --git a/arch/avr32/Kconfig b/arch/avr32/Kconfig
index bdc3558..7c9005a 100644
--- a/arch/avr32/Kconfig
+++ b/arch/avr32/Kconfig
@@ -55,7 +55,6 @@ config GENERIC_CALIBRATE_DELAY
 
 config GENERIC_BUG
 	def_bool y
-	depends on BUG
 
 source "init/Kconfig"
 
diff --git a/arch/blackfin/Kconfig b/arch/blackfin/Kconfig
index a117652..637dc42 100644
--- a/arch/blackfin/Kconfig
+++ b/arch/blackfin/Kconfig
@@ -47,7 +47,6 @@ config GENERIC_CSUM
 
 config GENERIC_BUG
 	def_bool y
-	depends on BUG
 
 config ZONE_DMA
 	def_bool y
diff --git a/arch/h8300/Kconfig b/arch/h8300/Kconfig
index 303e4f9..88848da 100644
--- a/arch/h8300/Kconfig
+++ b/arch/h8300/Kconfig
@@ -56,7 +56,6 @@ config GENERIC_CALIBRATE_DELAY
 
 config GENERIC_BUG
         bool
-        depends on BUG
 
 config TIME_LOW_RES
 	bool
diff --git a/arch/hexagon/Kconfig b/arch/hexagon/Kconfig
index 33a9792..f50cc8f 100644
--- a/arch/hexagon/Kconfig
+++ b/arch/hexagon/Kconfig
@@ -84,7 +84,6 @@ config STACKTRACE_SUPPORT
 
 config GENERIC_BUG
 	def_bool y
-	depends on BUG
 
 menu "Machine selection"
 
diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig
index 6507dab..5de1f8c 100644
--- a/arch/parisc/Kconfig
+++ b/arch/parisc/Kconfig
@@ -10,7 +10,6 @@ config PARISC
 	select RTC_CLASS
 	select RTC_DRV_GENERIC
 	select INIT_ALL_POSSIBLE
-	select BUG
 	select HAVE_PERF_EVENTS
 	select GENERIC_ATOMIC64 if !64BIT
 	select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
@@ -62,7 +61,6 @@ config ARCH_HAS_ILOG2_U64
 config GENERIC_BUG
 	bool
 	default y
-	depends on BUG
 
 config GENERIC_HWEIGHT
 	bool
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index c33e3ad..34f4ca9 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -187,7 +187,6 @@ config AUDIT_ARCH
 config GENERIC_BUG
 	bool
 	default y
-	depends on BUG
 
 config SYS_SUPPORTS_APM_EMULATION
 	default y if PMAC_APM_EMU
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index da183c5..5d7b3db 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -29,7 +29,7 @@ config GENERIC_HWEIGHT
 	def_bool y
 
 config GENERIC_BUG
-	def_bool y if BUG
+	def_bool y
 
 config GENERIC_BUG_RELATIVE_POINTERS
 	def_bool y
diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
index 8c868cf..d555e7f 100644
--- a/arch/sh/Kconfig
+++ b/arch/sh/Kconfig
@@ -84,7 +84,7 @@ config RWSEM_XCHGADD_ALGORITHM
 
 config GENERIC_BUG
 	def_bool y
-	depends on BUG && SUPERH32
+	depends on SUPERH32
 
 config GENERIC_CSUM
 	def_bool y
diff --git a/arch/um/Kconfig.common b/arch/um/Kconfig.common
index bceee66..7aae42a 100644
--- a/arch/um/Kconfig.common
+++ b/arch/um/Kconfig.common
@@ -53,7 +53,6 @@ config GENERIC_CALIBRATE_DELAY
 config GENERIC_BUG
 	bool
 	default y
-	depends on BUG
 
 config HZ
 	int
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 723e42e..a36e1b4 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -166,7 +166,6 @@ config GENERIC_ISA_DMA
 
 config GENERIC_BUG
 	def_bool y
-	depends on BUG
 	select GENERIC_BUG_RELATIVE_POINTERS if X86_64
 
 config GENERIC_BUG_RELATIVE_POINTERS
diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
index 7d10f96..5d50903 100644
--- a/include/asm-generic/bug.h
+++ b/include/asm-generic/bug.h
@@ -12,8 +12,6 @@
 #ifndef __ASSEMBLY__
 #include <linux/kernel.h>
 
-#ifdef CONFIG_BUG
-
 #ifdef CONFIG_GENERIC_BUG
 struct bug_entry {
 #ifndef CONFIG_GENERIC_BUG_RELATIVE_POINTERS
@@ -106,33 +104,6 @@ extern void warn_slowpath_null(const char *file, const int line);
 	unlikely(__ret_warn_on);					\
 })
 
-#else /* !CONFIG_BUG */
-#ifndef HAVE_ARCH_BUG
-#define BUG() do {} while(0)
-#endif
-
-#ifndef HAVE_ARCH_BUG_ON
-#define BUG_ON(condition) do { if (condition) ; } while(0)
-#endif
-
-#ifndef HAVE_ARCH_WARN_ON
-#define WARN_ON(condition) ({						\
-	int __ret_warn_on = !!(condition);				\
-	unlikely(__ret_warn_on);					\
-})
-#endif
-
-#ifndef WARN
-#define WARN(condition, format...) ({					\
-	int __ret_warn_on = !!(condition);				\
-	unlikely(__ret_warn_on);					\
-})
-#endif
-
-#define WARN_TAINT(condition, taint, format...) WARN_ON(condition)
-
-#endif
-
 #define WARN_ON_ONCE(condition)	({				\
 	static bool __section(.data.unlikely) __warned;		\
 	int __ret_warn_once = !!(condition);			\
diff --git a/init/Kconfig b/init/Kconfig
index 7fb26a6..bc1dd49 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1360,16 +1360,6 @@ config PRINTK
 	  very difficult to diagnose system problems, saying N here is
 	  strongly discouraged.
 
-config BUG
-	bool "BUG() support" if EXPERT
-	default y
-	help
-          Disabling this option eliminates support for BUG and WARN, reducing
-          the size of your kernel image and potentially quietly ignoring
-          numerous fatal conditions. You should only consider disabling this
-          option for embedded systems with no facilities for reporting errors.
-          Just say Y.
-
 config ELF_CORE
 	depends on COREDUMP
 	default y
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 566cf2b..54b3251 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -700,7 +700,7 @@ config HAVE_DEBUG_BUGVERBOSE
 
 config DEBUG_BUGVERBOSE
 	bool "Verbose BUG() reporting (adds 70K)" if DEBUG_KERNEL && EXPERT
-	depends on BUG && (GENERIC_BUG || HAVE_DEBUG_BUGVERBOSE)
+	depends on GENERIC_BUG || HAVE_DEBUG_BUGVERBOSE
 	default y
 	help
 	  Say Y here to make BUG() panics output the file name and line number
-- 
1.7.7.6

[PATCH v2] arch: configuration issue, random return value when disable 'CONFIG_BUG'

[Chen Gang]

If user disable 'CONFIG_BUG' in menuconfig, many areas not only will
report compiling warnings, but also may return a random value from the
function when BUG().

In fact, most of architectures need always let 'CONFIG_BUG' enabled, so
'#ifdef CONFIG_BUG' is already not 'generic' enough in "include/asm-
generic/".

Also kernel has already provided the 'generic' implementation in
"include/asm-generic" when 'CONFIG_BUG' enabled. Even if we disable
'CONFIG_BUG', we also shall have to implement the BUG() in "include/asm-
generic", just like when 'CONFIG_BUG' enabled (at least, it is not the
minimal size implementation).

So need remove 'CONFIG_BUG', and let it always enabled everywhere, then
fix this issue.

The architectures which need their own architecture specific features
(e.g. minimal size implementation), can customize their own BUG() and
__WARN_TAINT() to give a better fix (e.g. use one inline asm code, then
followed by 'unreachable' function, or another more better fix ways).


Signed-off-by: Chen Gang <gang.chen@asianux.com>
---
 arch/arm/Kconfig          |    1 -
 arch/avr32/Kconfig        |    1 -
 arch/blackfin/Kconfig     |    1 -
 arch/h8300/Kconfig        |    1 -
 arch/hexagon/Kconfig      |    1 -
 arch/parisc/Kconfig       |    2 --
 arch/powerpc/Kconfig      |    1 -
 arch/s390/Kconfig         |    2 +-
 arch/sh/Kconfig           |    2 +-
 arch/um/Kconfig.common    |    1 -
 arch/x86/Kconfig          |    1 -
 include/asm-generic/bug.h |   29 -----------------------------
 init/Kconfig              |   10 ----------
 lib/Kconfig.debug         |    2 +-
 14 files changed, 3 insertions(+), 52 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index a7fc5ea..ea4a146 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -265,7 +265,6 @@ config PHYS_OFFSET
 
 config GENERIC_BUG
 	def_bool y
-	depends on BUG
 
 source "init/Kconfig"
 
diff --git a/arch/avr32/Kconfig b/arch/avr32/Kconfig
index bdc3558..7c9005a 100644
--- a/arch/avr32/Kconfig
+++ b/arch/avr32/Kconfig
@@ -55,7 +55,6 @@ config GENERIC_CALIBRATE_DELAY
 
 config GENERIC_BUG
 	def_bool y
-	depends on BUG
 
 source "init/Kconfig"
 
diff --git a/arch/blackfin/Kconfig b/arch/blackfin/Kconfig
index a117652..637dc42 100644
--- a/arch/blackfin/Kconfig
+++ b/arch/blackfin/Kconfig
@@ -47,7 +47,6 @@ config GENERIC_CSUM
 
 config GENERIC_BUG
 	def_bool y
-	depends on BUG
 
 config ZONE_DMA
 	def_bool y
diff --git a/arch/h8300/Kconfig b/arch/h8300/Kconfig
index 303e4f9..88848da 100644
--- a/arch/h8300/Kconfig
+++ b/arch/h8300/Kconfig
@@ -56,7 +56,6 @@ config GENERIC_CALIBRATE_DELAY
 
 config GENERIC_BUG
         bool
-        depends on BUG
 
 config TIME_LOW_RES
 	bool
diff --git a/arch/hexagon/Kconfig b/arch/hexagon/Kconfig
index 33a9792..f50cc8f 100644
--- a/arch/hexagon/Kconfig
+++ b/arch/hexagon/Kconfig
@@ -84,7 +84,6 @@ config STACKTRACE_SUPPORT
 
 config GENERIC_BUG
 	def_bool y
-	depends on BUG
 
 menu "Machine selection"
 
diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig
index 6507dab..5de1f8c 100644
--- a/arch/parisc/Kconfig
+++ b/arch/parisc/Kconfig
@@ -10,7 +10,6 @@ config PARISC
 	select RTC_CLASS
 	select RTC_DRV_GENERIC
 	select INIT_ALL_POSSIBLE
-	select BUG
 	select HAVE_PERF_EVENTS
 	select GENERIC_ATOMIC64 if !64BIT
 	select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
@@ -62,7 +61,6 @@ config ARCH_HAS_ILOG2_U64
 config GENERIC_BUG
 	bool
 	default y
-	depends on BUG
 
 config GENERIC_HWEIGHT
 	bool
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index c33e3ad..34f4ca9 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -187,7 +187,6 @@ config AUDIT_ARCH
 config GENERIC_BUG
 	bool
 	default y
-	depends on BUG
 
 config SYS_SUPPORTS_APM_EMULATION
 	default y if PMAC_APM_EMU
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index da183c5..5d7b3db 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -29,7 +29,7 @@ config GENERIC_HWEIGHT
 	def_bool y
 
 config GENERIC_BUG
-	def_bool y if BUG
+	def_bool y
 
 config GENERIC_BUG_RELATIVE_POINTERS
 	def_bool y
diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
index 8c868cf..d555e7f 100644
--- a/arch/sh/Kconfig
+++ b/arch/sh/Kconfig
@@ -84,7 +84,7 @@ config RWSEM_XCHGADD_ALGORITHM
 
 config GENERIC_BUG
 	def_bool y
-	depends on BUG && SUPERH32
+	depends on SUPERH32
 
 config GENERIC_CSUM
 	def_bool y
diff --git a/arch/um/Kconfig.common b/arch/um/Kconfig.common
index bceee66..7aae42a 100644
--- a/arch/um/Kconfig.common
+++ b/arch/um/Kconfig.common
@@ -53,7 +53,6 @@ config GENERIC_CALIBRATE_DELAY
 config GENERIC_BUG
 	bool
 	default y
-	depends on BUG
 
 config HZ
 	int
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 723e42e..a36e1b4 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -166,7 +166,6 @@ config GENERIC_ISA_DMA
 
 config GENERIC_BUG
 	def_bool y
-	depends on BUG
 	select GENERIC_BUG_RELATIVE_POINTERS if X86_64
 
 config GENERIC_BUG_RELATIVE_POINTERS
diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
index 7d10f96..5d50903 100644
--- a/include/asm-generic/bug.h
+++ b/include/asm-generic/bug.h
@@ -12,8 +12,6 @@
 #ifndef __ASSEMBLY__
 #include <linux/kernel.h>
 
-#ifdef CONFIG_BUG
-
 #ifdef CONFIG_GENERIC_BUG
 struct bug_entry {
 #ifndef CONFIG_GENERIC_BUG_RELATIVE_POINTERS
@@ -106,33 +104,6 @@ extern void warn_slowpath_null(const char *file, const int line);
 	unlikely(__ret_warn_on);					\
 })
 
-#else /* !CONFIG_BUG */
-#ifndef HAVE_ARCH_BUG
-#define BUG() do {} while(0)
-#endif
-
-#ifndef HAVE_ARCH_BUG_ON
-#define BUG_ON(condition) do { if (condition) ; } while(0)
-#endif
-
-#ifndef HAVE_ARCH_WARN_ON
-#define WARN_ON(condition) ({						\
-	int __ret_warn_on = !!(condition);				\
-	unlikely(__ret_warn_on);					\
-})
-#endif
-
-#ifndef WARN
-#define WARN(condition, format...) ({					\
-	int __ret_warn_on = !!(condition);				\
-	unlikely(__ret_warn_on);					\
-})
-#endif
-
-#define WARN_TAINT(condition, taint, format...) WARN_ON(condition)
-
-#endif
-
 #define WARN_ON_ONCE(condition)	({				\
 	static bool __section(.data.unlikely) __warned;		\
 	int __ret_warn_once = !!(condition);			\
diff --git a/init/Kconfig b/init/Kconfig
index 7fb26a6..bc1dd49 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1360,16 +1360,6 @@ config PRINTK
 	  very difficult to diagnose system problems, saying N here is
 	  strongly discouraged.
 
-config BUG
-	bool "BUG() support" if EXPERT
-	default y
-	help
-          Disabling this option eliminates support for BUG and WARN, reducing
-          the size of your kernel image and potentially quietly ignoring
-          numerous fatal conditions. You should only consider disabling this
-          option for embedded systems with no facilities for reporting errors.
-          Just say Y.
-
 config ELF_CORE
 	depends on COREDUMP
 	default y
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 566cf2b..54b3251 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -700,7 +700,7 @@ config HAVE_DEBUG_BUGVERBOSE
 
 config DEBUG_BUGVERBOSE
 	bool "Verbose BUG() reporting (adds 70K)" if DEBUG_KERNEL && EXPERT
-	depends on BUG && (GENERIC_BUG || HAVE_DEBUG_BUGVERBOSE)
+	depends on GENERIC_BUG || HAVE_DEBUG_BUGVERBOSE
 	default y
 	help
 	  Say Y here to make BUG() panics output the file name and line number
-- 
1.7.7.6

[PATCH v2] arch: configuration issue, random return value when disable 'CONFIG_BUG'

[Chen Gang]

If user disable 'CONFIG_BUG' in menuconfig, many areas not only will
report compiling warnings, but also may return a random value from the
function when BUG().

In fact, most of architectures need always let 'CONFIG_BUG' enabled, so
'#ifdef CONFIG_BUG' is already not 'generic' enough in "include/asm-
generic/".

Also kernel has already provided the 'generic' implementation in
"include/asm-generic" when 'CONFIG_BUG' enabled. Even if we disable
'CONFIG_BUG', we also shall have to implement the BUG() in "include/asm-
generic", just like when 'CONFIG_BUG' enabled (at least, it is not the
minimal size implementation).

So need remove 'CONFIG_BUG', and let it always enabled everywhere, then
fix this issue.

The architectures which need their own architecture specific features
(e.g. minimal size implementation), can customize their own BUG() and
__WARN_TAINT() to give a better fix (e.g. use one inline asm code, then
followed by 'unreachable' function, or another more better fix ways).


Signed-off-by: Chen Gang <gang.chen@asianux.com>
---
 arch/arm/Kconfig          |    1 -
 arch/avr32/Kconfig        |    1 -
 arch/blackfin/Kconfig     |    1 -
 arch/h8300/Kconfig        |    1 -
 arch/hexagon/Kconfig      |    1 -
 arch/parisc/Kconfig       |    2 --
 arch/powerpc/Kconfig      |    1 -
 arch/s390/Kconfig         |    2 +-
 arch/sh/Kconfig           |    2 +-
 arch/um/Kconfig.common    |    1 -
 arch/x86/Kconfig          |    1 -
 include/asm-generic/bug.h |   29 -----------------------------
 init/Kconfig              |   10 ----------
 lib/Kconfig.debug         |    2 +-
 14 files changed, 3 insertions(+), 52 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index a7fc5ea..ea4a146 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -265,7 +265,6 @@ config PHYS_OFFSET
 
 config GENERIC_BUG
 	def_bool y
-	depends on BUG
 
 source "init/Kconfig"
 
diff --git a/arch/avr32/Kconfig b/arch/avr32/Kconfig
index bdc3558..7c9005a 100644
--- a/arch/avr32/Kconfig
+++ b/arch/avr32/Kconfig
@@ -55,7 +55,6 @@ config GENERIC_CALIBRATE_DELAY
 
 config GENERIC_BUG
 	def_bool y
-	depends on BUG
 
 source "init/Kconfig"
 
diff --git a/arch/blackfin/Kconfig b/arch/blackfin/Kconfig
index a117652..637dc42 100644
--- a/arch/blackfin/Kconfig
+++ b/arch/blackfin/Kconfig
@@ -47,7 +47,6 @@ config GENERIC_CSUM
 
 config GENERIC_BUG
 	def_bool y
-	depends on BUG
 
 config ZONE_DMA
 	def_bool y
diff --git a/arch/h8300/Kconfig b/arch/h8300/Kconfig
index 303e4f9..88848da 100644
--- a/arch/h8300/Kconfig
+++ b/arch/h8300/Kconfig
@@ -56,7 +56,6 @@ config GENERIC_CALIBRATE_DELAY
 
 config GENERIC_BUG
         bool
-        depends on BUG
 
 config TIME_LOW_RES
 	bool
diff --git a/arch/hexagon/Kconfig b/arch/hexagon/Kconfig
index 33a9792..f50cc8f 100644
--- a/arch/hexagon/Kconfig
+++ b/arch/hexagon/Kconfig
@@ -84,7 +84,6 @@ config STACKTRACE_SUPPORT
 
 config GENERIC_BUG
 	def_bool y
-	depends on BUG
 
 menu "Machine selection"
 
diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig
index 6507dab..5de1f8c 100644
--- a/arch/parisc/Kconfig
+++ b/arch/parisc/Kconfig
@@ -10,7 +10,6 @@ config PARISC
 	select RTC_CLASS
 	select RTC_DRV_GENERIC
 	select INIT_ALL_POSSIBLE
-	select BUG
 	select HAVE_PERF_EVENTS
 	select GENERIC_ATOMIC64 if !64BIT
 	select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
@@ -62,7 +61,6 @@ config ARCH_HAS_ILOG2_U64
 config GENERIC_BUG
 	bool
 	default y
-	depends on BUG
 
 config GENERIC_HWEIGHT
 	bool
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index c33e3ad..34f4ca9 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -187,7 +187,6 @@ config AUDIT_ARCH
 config GENERIC_BUG
 	bool
 	default y
-	depends on BUG
 
 config SYS_SUPPORTS_APM_EMULATION
 	default y if PMAC_APM_EMU
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index da183c5..5d7b3db 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -29,7 +29,7 @@ config GENERIC_HWEIGHT
 	def_bool y
 
 config GENERIC_BUG
-	def_bool y if BUG
+	def_bool y
 
 config GENERIC_BUG_RELATIVE_POINTERS
 	def_bool y
diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
index 8c868cf..d555e7f 100644
--- a/arch/sh/Kconfig
+++ b/arch/sh/Kconfig
@@ -84,7 +84,7 @@ config RWSEM_XCHGADD_ALGORITHM
 
 config GENERIC_BUG
 	def_bool y
-	depends on BUG && SUPERH32
+	depends on SUPERH32
 
 config GENERIC_CSUM
 	def_bool y
diff --git a/arch/um/Kconfig.common b/arch/um/Kconfig.common
index bceee66..7aae42a 100644
--- a/arch/um/Kconfig.common
+++ b/arch/um/Kconfig.common
@@ -53,7 +53,6 @@ config GENERIC_CALIBRATE_DELAY
 config GENERIC_BUG
 	bool
 	default y
-	depends on BUG
 
 config HZ
 	int
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 723e42e..a36e1b4 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -166,7 +166,6 @@ config GENERIC_ISA_DMA
 
 config GENERIC_BUG
 	def_bool y
-	depends on BUG
 	select GENERIC_BUG_RELATIVE_POINTERS if X86_64
 
 config GENERIC_BUG_RELATIVE_POINTERS
diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
index 7d10f96..5d50903 100644
--- a/include/asm-generic/bug.h
+++ b/include/asm-generic/bug.h
@@ -12,8 +12,6 @@
 #ifndef __ASSEMBLY__
 #include <linux/kernel.h>
 
-#ifdef CONFIG_BUG
-
 #ifdef CONFIG_GENERIC_BUG
 struct bug_entry {
 #ifndef CONFIG_GENERIC_BUG_RELATIVE_POINTERS
@@ -106,33 +104,6 @@ extern void warn_slowpath_null(const char *file, const int line);
 	unlikely(__ret_warn_on);					\
 })
 
-#else /* !CONFIG_BUG */
-#ifndef HAVE_ARCH_BUG
-#define BUG() do {} while(0)
-#endif
-
-#ifndef HAVE_ARCH_BUG_ON
-#define BUG_ON(condition) do { if (condition) ; } while(0)
-#endif
-
-#ifndef HAVE_ARCH_WARN_ON
-#define WARN_ON(condition) ({						\
-	int __ret_warn_on = !!(condition);				\
-	unlikely(__ret_warn_on);					\
-})
-#endif
-
-#ifndef WARN
-#define WARN(condition, format...) ({					\
-	int __ret_warn_on = !!(condition);				\
-	unlikely(__ret_warn_on);					\
-})
-#endif
-
-#define WARN_TAINT(condition, taint, format...) WARN_ON(condition)
-
-#endif
-
 #define WARN_ON_ONCE(condition)	({				\
 	static bool __section(.data.unlikely) __warned;		\
 	int __ret_warn_once = !!(condition);			\
diff --git a/init/Kconfig b/init/Kconfig
index 7fb26a6..bc1dd49 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1360,16 +1360,6 @@ config PRINTK
 	  very difficult to diagnose system problems, saying N here is
 	  strongly discouraged.
 
-config BUG
-	bool "BUG() support" if EXPERT
-	default y
-	help
-          Disabling this option eliminates support for BUG and WARN, reducing
-          the size of your kernel image and potentially quietly ignoring
-          numerous fatal conditions. You should only consider disabling this
-          option for embedded systems with no facilities for reporting errors.
-          Just say Y.
-
 config ELF_CORE
 	depends on COREDUMP
 	default y
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 566cf2b..54b3251 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -700,7 +700,7 @@ config HAVE_DEBUG_BUGVERBOSE
 
 config DEBUG_BUGVERBOSE
 	bool "Verbose BUG() reporting (adds 70K)" if DEBUG_KERNEL && EXPERT
-	depends on BUG && (GENERIC_BUG || HAVE_DEBUG_BUGVERBOSE)
+	depends on GENERIC_BUG || HAVE_DEBUG_BUGVERBOSE
 	default y
 	help
 	  Say Y here to make BUG() panics output the file name and line number
-- 
1.7.7.6

[PATCH v2] arch: configuration issue, random return value when disable 'CONFIG_BUG'

[Chen Gang]

If user disable 'CONFIG_BUG' in menuconfig, many areas not only will
report compiling warnings, but also may return a random value from the
function when BUG().

In fact, most of architectures need always let 'CONFIG_BUG' enabled, so
'#ifdef CONFIG_BUG' is already not 'generic' enough in "include/asm-
generic/".

Also kernel has already provided the 'generic' implementation in
"include/asm-generic" when 'CONFIG_BUG' enabled. Even if we disable
'CONFIG_BUG', we also shall have to implement the BUG() in "include/asm-
generic", just like when 'CONFIG_BUG' enabled (at least, it is not the
minimal size implementation).

So need remove 'CONFIG_BUG', and let it always enabled everywhere, then
fix this issue.

The architectures which need their own architecture specific features
(e.g. minimal size implementation), can customize their own BUG() and
__WARN_TAINT() to give a better fix (e.g. use one inline asm code, then
followed by 'unreachable' function, or another more better fix ways).


Signed-off-by: Chen Gang <gang.chen@asianux.com>
---
 arch/arm/Kconfig          |    1 -
 arch/avr32/Kconfig        |    1 -
 arch/blackfin/Kconfig     |    1 -
 arch/h8300/Kconfig        |    1 -
 arch/hexagon/Kconfig      |    1 -
 arch/parisc/Kconfig       |    2 --
 arch/powerpc/Kconfig      |    1 -
 arch/s390/Kconfig         |    2 +-
 arch/sh/Kconfig           |    2 +-
 arch/um/Kconfig.common    |    1 -
 arch/x86/Kconfig          |    1 -
 include/asm-generic/bug.h |   29 -----------------------------
 init/Kconfig              |   10 ----------
 lib/Kconfig.debug         |    2 +-
 14 files changed, 3 insertions(+), 52 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index a7fc5ea..ea4a146 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -265,7 +265,6 @@ config PHYS_OFFSET
 
 config GENERIC_BUG
 	def_bool y
-	depends on BUG
 
 source "init/Kconfig"
 
diff --git a/arch/avr32/Kconfig b/arch/avr32/Kconfig
index bdc3558..7c9005a 100644
--- a/arch/avr32/Kconfig
+++ b/arch/avr32/Kconfig
@@ -55,7 +55,6 @@ config GENERIC_CALIBRATE_DELAY
 
 config GENERIC_BUG
 	def_bool y
-	depends on BUG
 
 source "init/Kconfig"
 
diff --git a/arch/blackfin/Kconfig b/arch/blackfin/Kconfig
index a117652..637dc42 100644
--- a/arch/blackfin/Kconfig
+++ b/arch/blackfin/Kconfig
@@ -47,7 +47,6 @@ config GENERIC_CSUM
 
 config GENERIC_BUG
 	def_bool y
-	depends on BUG
 
 config ZONE_DMA
 	def_bool y
diff --git a/arch/h8300/Kconfig b/arch/h8300/Kconfig
index 303e4f9..88848da 100644
--- a/arch/h8300/Kconfig
+++ b/arch/h8300/Kconfig
@@ -56,7 +56,6 @@ config GENERIC_CALIBRATE_DELAY
 
 config GENERIC_BUG
         bool
-        depends on BUG
 
 config TIME_LOW_RES
 	bool
diff --git a/arch/hexagon/Kconfig b/arch/hexagon/Kconfig
index 33a9792..f50cc8f 100644
--- a/arch/hexagon/Kconfig
+++ b/arch/hexagon/Kconfig
@@ -84,7 +84,6 @@ config STACKTRACE_SUPPORT
 
 config GENERIC_BUG
 	def_bool y
-	depends on BUG
 
 menu "Machine selection"
 
diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig
index 6507dab..5de1f8c 100644
--- a/arch/parisc/Kconfig
+++ b/arch/parisc/Kconfig
@@ -10,7 +10,6 @@ config PARISC
 	select RTC_CLASS
 	select RTC_DRV_GENERIC
 	select INIT_ALL_POSSIBLE
-	select BUG
 	select HAVE_PERF_EVENTS
 	select GENERIC_ATOMIC64 if !64BIT
 	select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
@@ -62,7 +61,6 @@ config ARCH_HAS_ILOG2_U64
 config GENERIC_BUG
 	bool
 	default y
-	depends on BUG
 
 config GENERIC_HWEIGHT
 	bool
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index c33e3ad..34f4ca9 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -187,7 +187,6 @@ config AUDIT_ARCH
 config GENERIC_BUG
 	bool
 	default y
-	depends on BUG
 
 config SYS_SUPPORTS_APM_EMULATION
 	default y if PMAC_APM_EMU
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index da183c5..5d7b3db 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -29,7 +29,7 @@ config GENERIC_HWEIGHT
 	def_bool y
 
 config GENERIC_BUG
-	def_bool y if BUG
+	def_bool y
 
 config GENERIC_BUG_RELATIVE_POINTERS
 	def_bool y
diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
index 8c868cf..d555e7f 100644
--- a/arch/sh/Kconfig
+++ b/arch/sh/Kconfig
@@ -84,7 +84,7 @@ config RWSEM_XCHGADD_ALGORITHM
 
 config GENERIC_BUG
 	def_bool y
-	depends on BUG && SUPERH32
+	depends on SUPERH32
 
 config GENERIC_CSUM
 	def_bool y
diff --git a/arch/um/Kconfig.common b/arch/um/Kconfig.common
index bceee66..7aae42a 100644
--- a/arch/um/Kconfig.common
+++ b/arch/um/Kconfig.common
@@ -53,7 +53,6 @@ config GENERIC_CALIBRATE_DELAY
 config GENERIC_BUG
 	bool
 	default y
-	depends on BUG
 
 config HZ
 	int
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 723e42e..a36e1b4 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -166,7 +166,6 @@ config GENERIC_ISA_DMA
 
 config GENERIC_BUG
 	def_bool y
-	depends on BUG
 	select GENERIC_BUG_RELATIVE_POINTERS if X86_64
 
 config GENERIC_BUG_RELATIVE_POINTERS
diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
index 7d10f96..5d50903 100644
--- a/include/asm-generic/bug.h
+++ b/include/asm-generic/bug.h
@@ -12,8 +12,6 @@
 #ifndef __ASSEMBLY__
 #include <linux/kernel.h>
 
-#ifdef CONFIG_BUG
-
 #ifdef CONFIG_GENERIC_BUG
 struct bug_entry {
 #ifndef CONFIG_GENERIC_BUG_RELATIVE_POINTERS
@@ -106,33 +104,6 @@ extern void warn_slowpath_null(const char *file, const int line);
 	unlikely(__ret_warn_on);					\
 })
 
-#else /* !CONFIG_BUG */
-#ifndef HAVE_ARCH_BUG
-#define BUG() do {} while(0)
-#endif
-
-#ifndef HAVE_ARCH_BUG_ON
-#define BUG_ON(condition) do { if (condition) ; } while(0)
-#endif
-
-#ifndef HAVE_ARCH_WARN_ON
-#define WARN_ON(condition) ({						\
-	int __ret_warn_on = !!(condition);				\
-	unlikely(__ret_warn_on);					\
-})
-#endif
-
-#ifndef WARN
-#define WARN(condition, format...) ({					\
-	int __ret_warn_on = !!(condition);				\
-	unlikely(__ret_warn_on);					\
-})
-#endif
-
-#define WARN_TAINT(condition, taint, format...) WARN_ON(condition)
-
-#endif
-
 #define WARN_ON_ONCE(condition)	({				\
 	static bool __section(.data.unlikely) __warned;		\
 	int __ret_warn_once = !!(condition);			\
diff --git a/init/Kconfig b/init/Kconfig
index 7fb26a6..bc1dd49 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1360,16 +1360,6 @@ config PRINTK
 	  very difficult to diagnose system problems, saying N here is
 	  strongly discouraged.
 
-config BUG
-	bool "BUG() support" if EXPERT
-	default y
-	help
-          Disabling this option eliminates support for BUG and WARN, reducing
-          the size of your kernel image and potentially quietly ignoring
-          numerous fatal conditions. You should only consider disabling this
-          option for embedded systems with no facilities for reporting errors.
-          Just say Y.
-
 config ELF_CORE
 	depends on COREDUMP
 	default y
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 566cf2b..54b3251 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -700,7 +700,7 @@ config HAVE_DEBUG_BUGVERBOSE
 
 config DEBUG_BUGVERBOSE
 	bool "Verbose BUG() reporting (adds 70K)" if DEBUG_KERNEL && EXPERT
-	depends on BUG && (GENERIC_BUG || HAVE_DEBUG_BUGVERBOSE)
+	depends on GENERIC_BUG || HAVE_DEBUG_BUGVERBOSE
 	default y
 	help
 	  Say Y here to make BUG() panics output the file name and line number
-- 
1.7.7.6

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Ingo Molnar]

* Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:

> So, if you want to use this, then you should update the CONFIG_BUG text 
> to include a warning to this effect:
> 
>      Warning: if CONFIG_BUG is turned off, and control flow reaches
>      a BUG(), the system behaviour will be undefined.
> 
> so that people can make an informed choice about this, because at the
> moment:
> 
>           Disabling this option eliminates support for BUG and WARN, reducing
>           the size of your kernel image and potentially quietly ignoring
>           numerous fatal conditions. You should only consider disabling this
>           option for embedded systems with no facilities for reporting errors.
>           Just say Y.
> 
> will become completely misleading.  Turning this option off will _not_ 
> result in "quietly ignoring numerous fatal conditions".

I'm fine with adding your text as a clarification - but I think 'quietly 
ignoring fatal conditions' very much implies an undefined outcome if that 
unexpected condition does occur: the code might crash, it might corrupt 
memory or it might do some other unexpected thing.

There are many other places that do a BUG_ON() of a NULL pointer or so, or 
of a zero refcount, or a not held lock - and turning the BUG_ON() off 
makes the code unpredictable _anyway_ - even if the compiler does not 
notice an uninitialized variable.

So pretty much any weakening of BUG_ON() _will_ make the kernel more 
unpredictable.

> And I come back to one of my previous arguments - is it not better to 
> panic() if we hit one of these conditions so that the system can try to 
> do a panic-reboot rather than continue blindly into the unknown?

It will often continue blindly into the unknown even if the compiler is 
happy ...

The only difference is that it's "unpredictable" in a way not visible from 
the C code: the code won't necessarily fall through the BUG() when hitting 
that condition - although in practice it probably will.

So I think the same principle applies to it as to any other debugging 
code: it's fine to be able to turn debugging off. It's a performance 
versus kernel robustness/determinism trade-off.

Thanks,

	Ingo

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Ingo Molnar]

* Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:

> So, if you want to use this, then you should update the CONFIG_BUG text 
> to include a warning to this effect:
> 
>      Warning: if CONFIG_BUG is turned off, and control flow reaches
>      a BUG(), the system behaviour will be undefined.
> 
> so that people can make an informed choice about this, because at the
> moment:
> 
>           Disabling this option eliminates support for BUG and WARN, reducing
>           the size of your kernel image and potentially quietly ignoring
>           numerous fatal conditions. You should only consider disabling this
>           option for embedded systems with no facilities for reporting errors.
>           Just say Y.
> 
> will become completely misleading.  Turning this option off will _not_ 
> result in "quietly ignoring numerous fatal conditions".

I'm fine with adding your text as a clarification - but I think 'quietly 
ignoring fatal conditions' very much implies an undefined outcome if that 
unexpected condition does occur: the code might crash, it might corrupt 
memory or it might do some other unexpected thing.

There are many other places that do a BUG_ON() of a NULL pointer or so, or 
of a zero refcount, or a not held lock - and turning the BUG_ON() off 
makes the code unpredictable _anyway_ - even if the compiler does not 
notice an uninitialized variable.

So pretty much any weakening of BUG_ON() _will_ make the kernel more 
unpredictable.

> And I come back to one of my previous arguments - is it not better to 
> panic() if we hit one of these conditions so that the system can try to 
> do a panic-reboot rather than continue blindly into the unknown?

It will often continue blindly into the unknown even if the compiler is 
happy ...

The only difference is that it's "unpredictable" in a way not visible from 
the C code: the code won't necessarily fall through the BUG() when hitting 
that condition - although in practice it probably will.

So I think the same principle applies to it as to any other debugging 
code: it's fine to be able to turn debugging off. It's a performance 
versus kernel robustness/determinism trade-off.

Thanks,

	Ingo

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Ingo Molnar]

* Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:

> So, if you want to use this, then you should update the CONFIG_BUG text 
> to include a warning to this effect:
> 
>      Warning: if CONFIG_BUG is turned off, and control flow reaches
>      a BUG(), the system behaviour will be undefined.
> 
> so that people can make an informed choice about this, because at the
> moment:
> 
>           Disabling this option eliminates support for BUG and WARN, reducing
>           the size of your kernel image and potentially quietly ignoring
>           numerous fatal conditions. You should only consider disabling this
>           option for embedded systems with no facilities for reporting errors.
>           Just say Y.
> 
> will become completely misleading.  Turning this option off will _not_ 
> result in "quietly ignoring numerous fatal conditions".

I'm fine with adding your text as a clarification - but I think 'quietly 
ignoring fatal conditions' very much implies an undefined outcome if that 
unexpected condition does occur: the code might crash, it might corrupt 
memory or it might do some other unexpected thing.

There are many other places that do a BUG_ON() of a NULL pointer or so, or 
of a zero refcount, or a not held lock - and turning the BUG_ON() off 
makes the code unpredictable _anyway_ - even if the compiler does not 
notice an uninitialized variable.

So pretty much any weakening of BUG_ON() _will_ make the kernel more 
unpredictable.

> And I come back to one of my previous arguments - is it not better to 
> panic() if we hit one of these conditions so that the system can try to 
> do a panic-reboot rather than continue blindly into the unknown?

It will often continue blindly into the unknown even if the compiler is 
happy ...

The only difference is that it's "unpredictable" in a way not visible from 
the C code: the code won't necessarily fall through the BUG() when hitting 
that condition - although in practice it probably will.

So I think the same principle applies to it as to any other debugging 
code: it's fine to be able to turn debugging off. It's a performance 
versus kernel robustness/determinism trade-off.

Thanks,

	Ingo

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Ingo Molnar]

* Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:

> So, if you want to use this, then you should update the CONFIG_BUG text 
> to include a warning to this effect:
> 
>      Warning: if CONFIG_BUG is turned off, and control flow reaches
>      a BUG(), the system behaviour will be undefined.
> 
> so that people can make an informed choice about this, because at the
> moment:
> 
>           Disabling this option eliminates support for BUG and WARN, reducing
>           the size of your kernel image and potentially quietly ignoring
>           numerous fatal conditions. You should only consider disabling this
>           option for embedded systems with no facilities for reporting errors.
>           Just say Y.
> 
> will become completely misleading.  Turning this option off will _not_ 
> result in "quietly ignoring numerous fatal conditions".

I'm fine with adding your text as a clarification - but I think 'quietly 
ignoring fatal conditions' very much implies an undefined outcome if that 
unexpected condition does occur: the code might crash, it might corrupt 
memory or it might do some other unexpected thing.

There are many other places that do a BUG_ON() of a NULL pointer or so, or 
of a zero refcount, or a not held lock - and turning the BUG_ON() off 
makes the code unpredictable _anyway_ - even if the compiler does not 
notice an uninitialized variable.

So pretty much any weakening of BUG_ON() _will_ make the kernel more 
unpredictable.

> And I come back to one of my previous arguments - is it not better to 
> panic() if we hit one of these conditions so that the system can try to 
> do a panic-reboot rather than continue blindly into the unknown?

It will often continue blindly into the unknown even if the compiler is 
happy ...

The only difference is that it's "unpredictable" in a way not visible from 
the C code: the code won't necessarily fall through the BUG() when hitting 
that condition - although in practice it probably will.

So I think the same principle applies to it as to any other debugging 
code: it's fine to be able to turn debugging off. It's a performance 
versus kernel robustness/determinism trade-off.

Thanks,

	Ingo

[PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Ingo Molnar]

* Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:

> So, if you want to use this, then you should update the CONFIG_BUG text 
> to include a warning to this effect:
> 
>      Warning: if CONFIG_BUG is turned off, and control flow reaches
>      a BUG(), the system behaviour will be undefined.
> 
> so that people can make an informed choice about this, because at the
> moment:
> 
>           Disabling this option eliminates support for BUG and WARN, reducing
>           the size of your kernel image and potentially quietly ignoring
>           numerous fatal conditions. You should only consider disabling this
>           option for embedded systems with no facilities for reporting errors.
>           Just say Y.
> 
> will become completely misleading.  Turning this option off will _not_ 
> result in "quietly ignoring numerous fatal conditions".

I'm fine with adding your text as a clarification - but I think 'quietly 
ignoring fatal conditions' very much implies an undefined outcome if that 
unexpected condition does occur: the code might crash, it might corrupt 
memory or it might do some other unexpected thing.

There are many other places that do a BUG_ON() of a NULL pointer or so, or 
of a zero refcount, or a not held lock - and turning the BUG_ON() off 
makes the code unpredictable _anyway_ - even if the compiler does not 
notice an uninitialized variable.

So pretty much any weakening of BUG_ON() _will_ make the kernel more 
unpredictable.

> And I come back to one of my previous arguments - is it not better to 
> panic() if we hit one of these conditions so that the system can try to 
> do a panic-reboot rather than continue blindly into the unknown?

It will often continue blindly into the unknown even if the compiler is 
happy ...

The only difference is that it's "unpredictable" in a way not visible from 
the C code: the code won't necessarily fall through the BUG() when hitting 
that condition - although in practice it probably will.

So I think the same principle applies to it as to any other debugging 
code: it's fine to be able to turn debugging off. It's a performance 
versus kernel robustness/determinism trade-off.

Thanks,

	Ingo

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Ingo Molnar]

* Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:

> So, if you want to use this, then you should update the CONFIG_BUG text 
> to include a warning to this effect:
> 
>      Warning: if CONFIG_BUG is turned off, and control flow reaches
>      a BUG(), the system behaviour will be undefined.
> 
> so that people can make an informed choice about this, because at the
> moment:
> 
>           Disabling this option eliminates support for BUG and WARN, reducing
>           the size of your kernel image and potentially quietly ignoring
>           numerous fatal conditions. You should only consider disabling this
>           option for embedded systems with no facilities for reporting errors.
>           Just say Y.
> 
> will become completely misleading.  Turning this option off will _not_ 
> result in "quietly ignoring numerous fatal conditions".

I'm fine with adding your text as a clarification - but I think 'quietly 
ignoring fatal conditions' very much implies an undefined outcome if that 
unexpected condition does occur: the code might crash, it might corrupt 
memory or it might do some other unexpected thing.

There are many other places that do a BUG_ON() of a NULL pointer or so, or 
of a zero refcount, or a not held lock - and turning the BUG_ON() off 
makes the code unpredictable _anyway_ - even if the compiler does not 
notice an uninitialized variable.

So pretty much any weakening of BUG_ON() _will_ make the kernel more 
unpredictable.

> And I come back to one of my previous arguments - is it not better to 
> panic() if we hit one of these conditions so that the system can try to 
> do a panic-reboot rather than continue blindly into the unknown?

It will often continue blindly into the unknown even if the compiler is 
happy ...

The only difference is that it's "unpredictable" in a way not visible from 
the C code: the code won't necessarily fall through the BUG() when hitting 
that condition - although in practice it probably will.

So I think the same principle applies to it as to any other debugging 
code: it's fine to be able to turn debugging off. It's a performance 
versus kernel robustness/determinism trade-off.

Thanks,

	Ingo

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Ingo Molnar]

* Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:

> So, if you want to use this, then you should update the CONFIG_BUG text 
> to include a warning to this effect:
> 
>      Warning: if CONFIG_BUG is turned off, and control flow reaches
>      a BUG(), the system behaviour will be undefined.
> 
> so that people can make an informed choice about this, because at the
> moment:
> 
>           Disabling this option eliminates support for BUG and WARN, reducing
>           the size of your kernel image and potentially quietly ignoring
>           numerous fatal conditions. You should only consider disabling this
>           option for embedded systems with no facilities for reporting errors.
>           Just say Y.
> 
> will become completely misleading.  Turning this option off will _not_ 
> result in "quietly ignoring numerous fatal conditions".

I'm fine with adding your text as a clarification - but I think 'quietly 
ignoring fatal conditions' very much implies an undefined outcome if that 
unexpected condition does occur: the code might crash, it might corrupt 
memory or it might do some other unexpected thing.

There are many other places that do a BUG_ON() of a NULL pointer or so, or 
of a zero refcount, or a not held lock - and turning the BUG_ON() off 
makes the code unpredictable _anyway_ - even if the compiler does not 
notice an uninitialized variable.

So pretty much any weakening of BUG_ON() _will_ make the kernel more 
unpredictable.

> And I come back to one of my previous arguments - is it not better to 
> panic() if we hit one of these conditions so that the system can try to 
> do a panic-reboot rather than continue blindly into the unknown?

It will often continue blindly into the unknown even if the compiler is 
happy ...

The only difference is that it's "unpredictable" in a way not visible from 
the C code: the code won't necessarily fall through the BUG() when hitting 
that condition - although in practice it probably will.

So I think the same principle applies to it as to any other debugging 
code: it's fine to be able to turn debugging off. It's a performance 
versus kernel robustness/determinism trade-off.

Thanks,

	Ingo

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Chen Gang]

On 05/28/2013 04:19 PM, Ingo Molnar wrote:
>> > And I come back to one of my previous arguments - is it not better to 
>> > panic() if we hit one of these conditions so that the system can try to 
>> > do a panic-reboot rather than continue blindly into the unknown?
> It will often continue blindly into the unknown even if the compiler is 
> happy ...
> 

For Server, it is necessary to always enable CONFIG_BUG and call panic()

When analyzing core dump or KDB trap, we have to assume that the kernel
has already "continued blindly", but lucky, we can get the core dump or
KDB trap finally (sometimes, we really even can not get core dump or KDB
trap).


For PC, it is useless to disable CONFIG_BUG

The PC memory has already large enough to skip the minimal size
optimization. And its speed is also high enough to skip the speed
improvement by minimal size optimization.


For Embedded system, some of architectures may disable CONFIG_BUG.

Embedded system are widely used in many area, so the requirement of each
architectures for BUG() may be different,

  some may need reboot as quickly as possible for urgent processing;
  some may need dead looping in BUG() for avoid user amazing;
    (if auto-reboot, users feel out of control, don't know what happens)
  some may still need panic() just like Server requirements.
  others may not care about it, just implement it as minimal size.



> The only difference is that i

t's "unpredictable" in a way not visible from
> the C code: the code won't necessarily fall through the BUG() when hitting 
> that condition - although in practice it probably will.
> 
> So I think the same principle applies to it as to any other debugging 
> code: it's fine to be able to turn debugging off. It's a performance 
> versus kernel robustness/determinism trade-off.

'minimal size' for BUG() is belongs to some of Embedded system specific
features, it is not 'generic' enough to be in "include/asm-generic/".

If we still provide the "disable CONFIG_BUG", some of 'crazy users'
(e.g. randconfig) may make 'noise' to most of architectures.

So we need not provide "disable CONFIG_BUG" features for all platforms,
since most of architectures need not support it, and the architecture
which really need minimal size, can implement it by itself as a
architecture specific feature.



Thanks.
-- 
Chen Gang

Asianux Corporation

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Chen Gang]

On 05/28/2013 04:19 PM, Ingo Molnar wrote:
>> > And I come back to one of my previous arguments - is it not better to 
>> > panic() if we hit one of these conditions so that the system can try to 
>> > do a panic-reboot rather than continue blindly into the unknown?
> It will often continue blindly into the unknown even if the compiler is 
> happy ...
> 

For Server, it is necessary to always enable CONFIG_BUG and call panic()

When analyzing core dump or KDB trap, we have to assume that the kernel
has already "continued blindly", but lucky, we can get the core dump or
KDB trap finally (sometimes, we really even can not get core dump or KDB
trap).


For PC, it is useless to disable CONFIG_BUG

The PC memory has already large enough to skip the minimal size
optimization. And its speed is also high enough to skip the speed
improvement by minimal size optimization.


For Embedded system, some of architectures may disable CONFIG_BUG.

Embedded system are widely used in many area, so the requirement of each
architectures for BUG() may be different,

  some may need reboot as quickly as possible for urgent processing;
  some may need dead looping in BUG() for avoid user amazing;
    (if auto-reboot, users feel out of control, don't know what happens)
  some may still need panic() just like Server requirements.
  others may not care about it, just implement it as minimal size.



> The only difference is that i

t's "unpredictable" in a way not visible from
> the C code: the code won't necessarily fall through the BUG() when hitting 
> that condition - although in practice it probably will.
> 
> So I think the same principle applies to it as to any other debugging 
> code: it's fine to be able to turn debugging off. It's a performance 
> versus kernel robustness/determinism trade-off.

'minimal size' for BUG() is belongs to some of Embedded system specific
features, it is not 'generic' enough to be in "include/asm-generic/".

If we still provide the "disable CONFIG_BUG", some of 'crazy users'
(e.g. randconfig) may make 'noise' to most of architectures.

So we need not provide "disable CONFIG_BUG" features for all platforms,
since most of architectures need not support it, and the architecture
which really need minimal size, can implement it by itself as a
architecture specific feature.



Thanks.
-- 
Chen Gang

Asianux Corporation

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Chen Gang]

On 05/28/2013 04:19 PM, Ingo Molnar wrote:
>> > And I come back to one of my previous arguments - is it not better to 
>> > panic() if we hit one of these conditions so that the system can try to 
>> > do a panic-reboot rather than continue blindly into the unknown?
> It will often continue blindly into the unknown even if the compiler is 
> happy ...
> 

For Server, it is necessary to always enable CONFIG_BUG and call panic()

When analyzing core dump or KDB trap, we have to assume that the kernel
has already "continued blindly", but lucky, we can get the core dump or
KDB trap finally (sometimes, we really even can not get core dump or KDB
trap).


For PC, it is useless to disable CONFIG_BUG

The PC memory has already large enough to skip the minimal size
optimization. And its speed is also high enough to skip the speed
improvement by minimal size optimization.


For Embedded system, some of architectures may disable CONFIG_BUG.

Embedded system are widely used in many area, so the requirement of each
architectures for BUG() may be different,

  some may need reboot as quickly as possible for urgent processing;
  some may need dead looping in BUG() for avoid user amazing;
    (if auto-reboot, users feel out of control, don't know what happens)
  some may still need panic() just like Server requirements.
  others may not care about it, just implement it as minimal size.



> The only difference is that i

t's "unpredictable" in a way not visible from
> the C code: the code won't necessarily fall through the BUG() when hitting 
> that condition - although in practice it probably will.
> 
> So I think the same principle applies to it as to any other debugging 
> code: it's fine to be able to turn debugging off. It's a performance 
> versus kernel robustness/determinism trade-off.

'minimal size' for BUG() is belongs to some of Embedded system specific
features, it is not 'generic' enough to be in "include/asm-generic/".

If we still provide the "disable CONFIG_BUG", some of 'crazy users'
(e.g. randconfig) may make 'noise' to most of architectures.

So we need not provide "disable CONFIG_BUG" features for all platforms,
since most of architectures need not support it, and the architecture
which really need minimal size, can implement it by itself as a
architecture specific feature.



Thanks.
-- 
Chen Gang

Asianux Corporation

[PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Chen Gang]

On 05/28/2013 04:19 PM, Ingo Molnar wrote:
>> > And I come back to one of my previous arguments - is it not better to 
>> > panic() if we hit one of these conditions so that the system can try to 
>> > do a panic-reboot rather than continue blindly into the unknown?
> It will often continue blindly into the unknown even if the compiler is 
> happy ...
> 

For Server, it is necessary to always enable CONFIG_BUG and call panic()

When analyzing core dump or KDB trap, we have to assume that the kernel
has already "continued blindly", but lucky, we can get the core dump or
KDB trap finally (sometimes, we really even can not get core dump or KDB
trap).


For PC, it is useless to disable CONFIG_BUG

The PC memory has already large enough to skip the minimal size
optimization. And its speed is also high enough to skip the speed
improvement by minimal size optimization.


For Embedded system, some of architectures may disable CONFIG_BUG.

Embedded system are widely used in many area, so the requirement of each
architectures for BUG() may be different,

  some may need reboot as quickly as possible for urgent processing;
  some may need dead looping in BUG() for avoid user amazing;
    (if auto-reboot, users feel out of control, don't know what happens)
  some may still need panic() just like Server requirements.
  others may not care about it, just implement it as minimal size.



> The only difference is that i

t's "unpredictable" in a way not visible from
> the C code: the code won't necessarily fall through the BUG() when hitting 
> that condition - although in practice it probably will.
> 
> So I think the same principle applies to it as to any other debugging 
> code: it's fine to be able to turn debugging off. It's a performance 
> versus kernel robustness/determinism trade-off.

'minimal size' for BUG() is belongs to some of Embedded system specific
features, it is not 'generic' enough to be in "include/asm-generic/".

If we still provide the "disable CONFIG_BUG", some of 'crazy users'
(e.g. randconfig) may make 'noise' to most of architectures.

So we need not provide "disable CONFIG_BUG" features for all platforms,
since most of architectures need not support it, and the architecture
which really need minimal size, can implement it by itself as a
architecture specific feature.



Thanks.
-- 
Chen Gang

Asianux Corporation

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Chen Gang]

On 05/28/2013 04:19 PM, Ingo Molnar wrote:
>> > And I come back to one of my previous arguments - is it not better to 
>> > panic() if we hit one of these conditions so that the system can try to 
>> > do a panic-reboot rather than continue blindly into the unknown?
> It will often continue blindly into the unknown even if the compiler is 
> happy ...
> 

For Server, it is necessary to always enable CONFIG_BUG and call panic()

When analyzing core dump or KDB trap, we have to assume that the kernel
has already "continued blindly", but lucky, we can get the core dump or
KDB trap finally (sometimes, we really even can not get core dump or KDB
trap).


For PC, it is useless to disable CONFIG_BUG

The PC memory has already large enough to skip the minimal size
optimization. And its speed is also high enough to skip the speed
improvement by minimal size optimization.


For Embedded system, some of architectures may disable CONFIG_BUG.

Embedded system are widely used in many area, so the requirement of each
architectures for BUG() may be different,

  some may need reboot as quickly as possible for urgent processing;
  some may need dead looping in BUG() for avoid user amazing;
    (if auto-reboot, users feel out of control, don't know what happens)
  some may still need panic() just like Server requirements.
  others may not care about it, just implement it as minimal size.



> The only difference is that i

t's "unpredictable" in a way not visible from
> the C code: the code won't necessarily fall through the BUG() when hitting 
> that condition - although in practice it probably will.
> 
> So I think the same principle applies to it as to any other debugging 
> code: it's fine to be able to turn debugging off. It's a performance 
> versus kernel robustness/determinism trade-off.

'minimal size' for BUG() is belongs to some of Embedded system specific
features, it is not 'generic' enough to be in "include/asm-generic/".

If we still provide the "disable CONFIG_BUG", some of 'crazy users'
(e.g. randconfig) may make 'noise' to most of architectures.

So we need not provide "disable CONFIG_BUG" features for all platforms,
since most of architectures need not support it, and the architecture
which really need minimal size, can implement it by itself as a
architecture specific feature.



Thanks.
-- 
Chen Gang

Asianux Corporation

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Arnd Bergmann]

On Tuesday 28 May 2013 10:19:10 Ingo Molnar wrote:
> 
> * Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> 
> > So, if you want to use this, then you should update the CONFIG_BUG text 
> > to include a warning to this effect:
> > 
> >      Warning: if CONFIG_BUG is turned off, and control flow reaches
> >      a BUG(), the system behaviour will be undefined.
> > 
> > so that people can make an informed choice about this, because at the
> > moment:
> > 
> >           Disabling this option eliminates support for BUG and WARN, reducing
> >           the size of your kernel image and potentially quietly ignoring
> >           numerous fatal conditions. You should only consider disabling this
> >           option for embedded systems with no facilities for reporting errors.
> >           Just say Y.
> > 
> > will become completely misleading.  Turning this option off will _not_ 
> > result in "quietly ignoring numerous fatal conditions".
> 
> I'm fine with adding your text as a clarification - but I think 'quietly 
> ignoring fatal conditions' very much implies an undefined outcome if that 
> unexpected condition does occur: the code might crash, it might corrupt 
> memory or it might do some other unexpected thing.
> 
> There are many other places that do a BUG_ON() of a NULL pointer or so, or 
> of a zero refcount, or a not held lock - and turning the BUG_ON() off 
> makes the code unpredictable _anyway_ - even if the compiler does not 
> notice an uninitialized variable.
> 
> So pretty much any weakening of BUG_ON() _will_ make the kernel more 
> unpredictable.

FWIW, I've run some size analyis using the ARM 'multi_v7_defconfig'
and gcc-4.8, using various definitions for BUG() and BUG_ON(), to
see how big the size improvement actually gets

1. Baseline: normal bug plus CONFIG_BUG_VERBOSE
   text    data     bss     dec     hex filename
3743196  224396  206812 4174404  3fb244 vmlinux-bugverbose

2. disabling CONFIG_BUG_VERBOSE, saving 0.6%
3716920  224380  206812 4148112  3f4b90 vmlinux-nobugverbose

3. #define BUG() panic(__func__), #define BUG_ON(c) if(c) BUG(), saving 1.0%
3701076  224384  206812 4132272  3f0db0 vmlinux-bug-panicfunc

3. #define BUG() panic(__func__), #define BUG_ON(c) if(c) BUG(), saving 1.5%
3678884  224400  206812 4110096  3eb710 vmlinux-bug-panic

4. #define BUG() unreachable(), saving 2.1%
3652636  224384  206812 4083832  3e5078 vmlinux-bug-unreachable

5. as 4, plus #define BUG_ON(c) if(c) unreachable(), saving 2.2%
3651108  224380  206812 4082300  3e4a7c vmlinux-bugon-unreachable

6. #define BUG() do{}while(0), saving 2.1%
3654264  224380  206812 4085456  3e56d0 vmlinux-nobug

7. as 6, plus #define BUG_ON if(0 && (c)) unreachable, saving 2.2%
3648392  223996  206748 4079136  3e3e20 vmlinux-no-bugon

8. my patch below, saving 1.8%
3666532  224380  206812 4097724  3e86bc obj-tmp/vmlinux

The gain of doing unreachable and letting the code run off whereever
is minimal compared to the current state of doing nothing, but it
avoids the warnings.

Same test using x86_defconfig:

1. CONFIG_BUG=y, CONFIG_BUGVERBOSE=n
10797859        1395648 1175552 13369059         cbfee3 vmlinux-x86-bug

2. CONFIG_BUG=n, saves 1.0%
10658553        1395584 1175552 13229689         c9de79 vmlinux-x86-nobug

3. with my patch, saves 0.8%
10684186        1395584 1175552 13255322         ca429a vmlinux-x86-archbug

Getting 1-2% savings in kernel size seems absolutely worth keeping the
option, but 0.2-0.4% left for getting reproducible behavior also seems
worthwhile. The result in the patch below.

This basically loses any of the BUG() reporting, but leaves the
logic to trap and kill the task in place when CONFIG_BUG is disabled.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>

diff --git a/arch/arm/include/asm/bug.h b/arch/arm/include/asm/bug.h
index 7af5c6c..f25e638 100644
--- a/arch/arm/include/asm/bug.h
+++ b/arch/arm/include/asm/bug.h
@@ -3,8 +3,6 @@
 
 #include <linux/linkage.h>
 
-#ifdef CONFIG_BUG
-
 /*
  * Use a suitable undefined instruction to use for ARM/Thumb2 bug handling.
  * We need to be careful not to conflict with those used by other modules and
@@ -51,10 +50,10 @@ do {								\
 	asm volatile(BUG_INSTR_TYPE #__value);			\
 	unreachable();						\
 } while (0)
 #endif  /* CONFIG_DEBUG_BUGVERBOSE */
 
 #define HAVE_ARCH_BUG
-#endif  /* CONFIG_BUG */
+#define HAVE_ARCH_BUG_ON
 
 #include <asm-generic/bug.h>
 
diff --git a/arch/x86/include/asm/bug.h b/arch/x86/include/asm/bug.h
index 2f03ff0..ba38ebb 100644
--- a/arch/x86/include/asm/bug.h
+++ b/arch/x86/include/asm/bug.h
@@ -1,7 +1,6 @@
 #ifndef _ASM_X86_BUG_H
 #define _ASM_X86_BUG_H
 
-#ifdef CONFIG_BUG
 #define HAVE_ARCH_BUG
 
 #ifdef CONFIG_DEBUG_BUGVERBOSE
@@ -33,8 +32,6 @@ do {								\
 } while (0)
 #endif
 
-#endif /* !CONFIG_BUG */
-
 #include <asm-generic/bug.h>
 
 #endif /* _ASM_X86_BUG_H */
diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
index 7d10f96..bbd2872 100644
--- a/include/asm-generic/bug.h
+++ b/include/asm-generic/bug.h
@@ -112,12 +112,13 @@ extern void warn_slowpath_null(const char *file, const int line);
 #endif
 
 #ifndef HAVE_ARCH_BUG_ON
-#define BUG_ON(condition) do { if (condition) ; } while(0)
+#define BUG_ON(condition) do { if (unlikely(condition)) BUG(); } while(0)
 #endif
 
 #ifndef HAVE_ARCH_WARN_ON
 #define WARN_ON(condition) ({						\
 	int __ret_warn_on = !!(condition);				\
+	(void)__ret_warn_on;						\
 	unlikely(__ret_warn_on);					\
 })
 #endif
@@ -125,6 +126,8 @@ extern void warn_slowpath_null(const char *file, const int line);
 #ifndef WARN
 #define WARN(condition, format...) ({					\
 	int __ret_warn_on = !!(condition);				\
+	if (0 && (__ret_warn_on))					\
+		printk(format);						\
 	unlikely(__ret_warn_on);					\
 })
 #endif

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Arnd Bergmann]

On Tuesday 28 May 2013 10:19:10 Ingo Molnar wrote:
> 
> * Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> 
> > So, if you want to use this, then you should update the CONFIG_BUG text 
> > to include a warning to this effect:
> > 
> >      Warning: if CONFIG_BUG is turned off, and control flow reaches
> >      a BUG(), the system behaviour will be undefined.
> > 
> > so that people can make an informed choice about this, because at the
> > moment:
> > 
> >           Disabling this option eliminates support for BUG and WARN, reducing
> >           the size of your kernel image and potentially quietly ignoring
> >           numerous fatal conditions. You should only consider disabling this
> >           option for embedded systems with no facilities for reporting errors.
> >           Just say Y.
> > 
> > will become completely misleading.  Turning this option off will _not_ 
> > result in "quietly ignoring numerous fatal conditions".
> 
> I'm fine with adding your text as a clarification - but I think 'quietly 
> ignoring fatal conditions' very much implies an undefined outcome if that 
> unexpected condition does occur: the code might crash, it might corrupt 
> memory or it might do some other unexpected thing.
> 
> There are many other places that do a BUG_ON() of a NULL pointer or so, or 
> of a zero refcount, or a not held lock - and turning the BUG_ON() off 
> makes the code unpredictable _anyway_ - even if the compiler does not 
> notice an uninitialized variable.
> 
> So pretty much any weakening of BUG_ON() _will_ make the kernel more 
> unpredictable.

FWIW, I've run some size analyis using the ARM 'multi_v7_defconfig'
and gcc-4.8, using various definitions for BUG() and BUG_ON(), to
see how big the size improvement actually gets

1. Baseline: normal bug plus CONFIG_BUG_VERBOSE
   text    data     bss     dec     hex filename
3743196  224396  206812 4174404  3fb244 vmlinux-bugverbose

2. disabling CONFIG_BUG_VERBOSE, saving 0.6%
3716920  224380  206812 4148112  3f4b90 vmlinux-nobugverbose

3. #define BUG() panic(__func__), #define BUG_ON(c) if(c) BUG(), saving 1.0%
3701076  224384  206812 4132272  3f0db0 vmlinux-bug-panicfunc

3. #define BUG() panic(__func__), #define BUG_ON(c) if(c) BUG(), saving 1.5%
3678884  224400  206812 4110096  3eb710 vmlinux-bug-panic

4. #define BUG() unreachable(), saving 2.1%
3652636  224384  206812 4083832  3e5078 vmlinux-bug-unreachable

5. as 4, plus #define BUG_ON(c) if(c) unreachable(), saving 2.2%
3651108  224380  206812 4082300  3e4a7c vmlinux-bugon-unreachable

6. #define BUG() do{}while(0), saving 2.1%
3654264  224380  206812 4085456  3e56d0 vmlinux-nobug

7. as 6, plus #define BUG_ON if(0 && (c)) unreachable, saving 2.2%
3648392  223996  206748 4079136  3e3e20 vmlinux-no-bugon

8. my patch below, saving 1.8%
3666532  224380  206812 4097724  3e86bc obj-tmp/vmlinux

The gain of doing unreachable and letting the code run off whereever
is minimal compared to the current state of doing nothing, but it
avoids the warnings.

Same test using x86_defconfig:

1. CONFIG_BUG=y, CONFIG_BUGVERBOSE=n
10797859        1395648 1175552 13369059         cbfee3 vmlinux-x86-bug

2. CONFIG_BUG=n, saves 1.0%
10658553        1395584 1175552 13229689         c9de79 vmlinux-x86-nobug

3. with my patch, saves 0.8%
10684186        1395584 1175552 13255322         ca429a vmlinux-x86-archbug

Getting 1-2% savings in kernel size seems absolutely worth keeping the
option, but 0.2-0.4% left for getting reproducible behavior also seems
worthwhile. The result in the patch below.

This basically loses any of the BUG() reporting, but leaves the
logic to trap and kill the task in place when CONFIG_BUG is disabled.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>

diff --git a/arch/arm/include/asm/bug.h b/arch/arm/include/asm/bug.h
index 7af5c6c..f25e638 100644
--- a/arch/arm/include/asm/bug.h
+++ b/arch/arm/include/asm/bug.h
@@ -3,8 +3,6 @@
 
 #include <linux/linkage.h>
 
-#ifdef CONFIG_BUG
-
 /*
  * Use a suitable undefined instruction to use for ARM/Thumb2 bug handling.
  * We need to be careful not to conflict with those used by other modules and
@@ -51,10 +50,10 @@ do {								\
 	asm volatile(BUG_INSTR_TYPE #__value);			\
 	unreachable();						\
 } while (0)
 #endif  /* CONFIG_DEBUG_BUGVERBOSE */
 
 #define HAVE_ARCH_BUG
-#endif  /* CONFIG_BUG */
+#define HAVE_ARCH_BUG_ON
 
 #include <asm-generic/bug.h>
 
diff --git a/arch/x86/include/asm/bug.h b/arch/x86/include/asm/bug.h
index 2f03ff0..ba38ebb 100644
--- a/arch/x86/include/asm/bug.h
+++ b/arch/x86/include/asm/bug.h
@@ -1,7 +1,6 @@
 #ifndef _ASM_X86_BUG_H
 #define _ASM_X86_BUG_H
 
-#ifdef CONFIG_BUG
 #define HAVE_ARCH_BUG
 
 #ifdef CONFIG_DEBUG_BUGVERBOSE
@@ -33,8 +32,6 @@ do {								\
 } while (0)
 #endif
 
-#endif /* !CONFIG_BUG */
-
 #include <asm-generic/bug.h>
 
 #endif /* _ASM_X86_BUG_H */
diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
index 7d10f96..bbd2872 100644
--- a/include/asm-generic/bug.h
+++ b/include/asm-generic/bug.h
@@ -112,12 +112,13 @@ extern void warn_slowpath_null(const char *file, const int line);
 #endif
 
 #ifndef HAVE_ARCH_BUG_ON
-#define BUG_ON(condition) do { if (condition) ; } while(0)
+#define BUG_ON(condition) do { if (unlikely(condition)) BUG(); } while(0)
 #endif
 
 #ifndef HAVE_ARCH_WARN_ON
 #define WARN_ON(condition) ({						\
 	int __ret_warn_on = !!(condition);				\
+	(void)__ret_warn_on;						\
 	unlikely(__ret_warn_on);					\
 })
 #endif
@@ -125,6 +126,8 @@ extern void warn_slowpath_null(const char *file, const int line);
 #ifndef WARN
 #define WARN(condition, format...) ({					\
 	int __ret_warn_on = !!(condition);				\
+	if (0 && (__ret_warn_on))					\
+		printk(format);						\
 	unlikely(__ret_warn_on);					\
 })
 #endif

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Arnd Bergmann]

On Tuesday 28 May 2013 10:19:10 Ingo Molnar wrote:
> 
> * Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> 
> > So, if you want to use this, then you should update the CONFIG_BUG text 
> > to include a warning to this effect:
> > 
> >      Warning: if CONFIG_BUG is turned off, and control flow reaches
> >      a BUG(), the system behaviour will be undefined.
> > 
> > so that people can make an informed choice about this, because at the
> > moment:
> > 
> >           Disabling this option eliminates support for BUG and WARN, reducing
> >           the size of your kernel image and potentially quietly ignoring
> >           numerous fatal conditions. You should only consider disabling this
> >           option for embedded systems with no facilities for reporting errors.
> >           Just say Y.
> > 
> > will become completely misleading.  Turning this option off will _not_ 
> > result in "quietly ignoring numerous fatal conditions".
> 
> I'm fine with adding your text as a clarification - but I think 'quietly 
> ignoring fatal conditions' very much implies an undefined outcome if that 
> unexpected condition does occur: the code might crash, it might corrupt 
> memory or it might do some other unexpected thing.
> 
> There are many other places that do a BUG_ON() of a NULL pointer or so, or 
> of a zero refcount, or a not held lock - and turning the BUG_ON() off 
> makes the code unpredictable _anyway_ - even if the compiler does not 
> notice an uninitialized variable.
> 
> So pretty much any weakening of BUG_ON() _will_ make the kernel more 
> unpredictable.

FWIW, I've run some size analyis using the ARM 'multi_v7_defconfig'
and gcc-4.8, using various definitions for BUG() and BUG_ON(), to
see how big the size improvement actually gets

1. Baseline: normal bug plus CONFIG_BUG_VERBOSE
   text    data     bss     dec     hex filename
3743196  224396  206812 4174404  3fb244 vmlinux-bugverbose

2. disabling CONFIG_BUG_VERBOSE, saving 0.6%
3716920  224380  206812 4148112  3f4b90 vmlinux-nobugverbose

3. #define BUG() panic(__func__), #define BUG_ON(c) if(c) BUG(), saving 1.0%
3701076  224384  206812 4132272  3f0db0 vmlinux-bug-panicfunc

3. #define BUG() panic(__func__), #define BUG_ON(c) if(c) BUG(), saving 1.5%
3678884  224400  206812 4110096  3eb710 vmlinux-bug-panic

4. #define BUG() unreachable(), saving 2.1%
3652636  224384  206812 4083832  3e5078 vmlinux-bug-unreachable

5. as 4, plus #define BUG_ON(c) if(c) unreachable(), saving 2.2%
3651108  224380  206812 4082300  3e4a7c vmlinux-bugon-unreachable

6. #define BUG() do{}while(0), saving 2.1%
3654264  224380  206812 4085456  3e56d0 vmlinux-nobug

7. as 6, plus #define BUG_ON if(0 && (c)) unreachable, saving 2.2%
3648392  223996  206748 4079136  3e3e20 vmlinux-no-bugon

8. my patch below, saving 1.8%
3666532  224380  206812 4097724  3e86bc obj-tmp/vmlinux

The gain of doing unreachable and letting the code run off whereever
is minimal compared to the current state of doing nothing, but it
avoids the warnings.

Same test using x86_defconfig:

1. CONFIG_BUG=y, CONFIG_BUGVERBOSE=n
10797859        1395648 1175552 13369059         cbfee3 vmlinux-x86-bug

2. CONFIG_BUG=n, saves 1.0%
10658553        1395584 1175552 13229689         c9de79 vmlinux-x86-nobug

3. with my patch, saves 0.8%
10684186        1395584 1175552 13255322         ca429a vmlinux-x86-archbug

Getting 1-2% savings in kernel size seems absolutely worth keeping the
option, but 0.2-0.4% left for getting reproducible behavior also seems
worthwhile. The result in the patch below.

This basically loses any of the BUG() reporting, but leaves the
logic to trap and kill the task in place when CONFIG_BUG is disabled.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>

diff --git a/arch/arm/include/asm/bug.h b/arch/arm/include/asm/bug.h
index 7af5c6c..f25e638 100644
--- a/arch/arm/include/asm/bug.h
+++ b/arch/arm/include/asm/bug.h
@@ -3,8 +3,6 @@
 
 #include <linux/linkage.h>
 
-#ifdef CONFIG_BUG
-
 /*
  * Use a suitable undefined instruction to use for ARM/Thumb2 bug handling.
  * We need to be careful not to conflict with those used by other modules and
@@ -51,10 +50,10 @@ do {								\
 	asm volatile(BUG_INSTR_TYPE #__value);			\
 	unreachable();						\
 } while (0)
 #endif  /* CONFIG_DEBUG_BUGVERBOSE */
 
 #define HAVE_ARCH_BUG
-#endif  /* CONFIG_BUG */
+#define HAVE_ARCH_BUG_ON
 
 #include <asm-generic/bug.h>
 
diff --git a/arch/x86/include/asm/bug.h b/arch/x86/include/asm/bug.h
index 2f03ff0..ba38ebb 100644
--- a/arch/x86/include/asm/bug.h
+++ b/arch/x86/include/asm/bug.h
@@ -1,7 +1,6 @@
 #ifndef _ASM_X86_BUG_H
 #define _ASM_X86_BUG_H
 
-#ifdef CONFIG_BUG
 #define HAVE_ARCH_BUG
 
 #ifdef CONFIG_DEBUG_BUGVERBOSE
@@ -33,8 +32,6 @@ do {								\
 } while (0)
 #endif
 
-#endif /* !CONFIG_BUG */
-
 #include <asm-generic/bug.h>
 
 #endif /* _ASM_X86_BUG_H */
diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
index 7d10f96..bbd2872 100644
--- a/include/asm-generic/bug.h
+++ b/include/asm-generic/bug.h
@@ -112,12 +112,13 @@ extern void warn_slowpath_null(const char *file, const int line);
 #endif
 
 #ifndef HAVE_ARCH_BUG_ON
-#define BUG_ON(condition) do { if (condition) ; } while(0)
+#define BUG_ON(condition) do { if (unlikely(condition)) BUG(); } while(0)
 #endif
 
 #ifndef HAVE_ARCH_WARN_ON
 #define WARN_ON(condition) ({						\
 	int __ret_warn_on = !!(condition);				\
+	(void)__ret_warn_on;						\
 	unlikely(__ret_warn_on);					\
 })
 #endif
@@ -125,6 +126,8 @@ extern void warn_slowpath_null(const char *file, const int line);
 #ifndef WARN
 #define WARN(condition, format...) ({					\
 	int __ret_warn_on = !!(condition);				\
+	if (0 && (__ret_warn_on))					\
+		printk(format);						\
 	unlikely(__ret_warn_on);					\
 })
 #endif

[PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Arnd Bergmann]

On Tuesday 28 May 2013 10:19:10 Ingo Molnar wrote:
> 
> * Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> 
> > So, if you want to use this, then you should update the CONFIG_BUG text 
> > to include a warning to this effect:
> > 
> >      Warning: if CONFIG_BUG is turned off, and control flow reaches
> >      a BUG(), the system behaviour will be undefined.
> > 
> > so that people can make an informed choice about this, because at the
> > moment:
> > 
> >           Disabling this option eliminates support for BUG and WARN, reducing
> >           the size of your kernel image and potentially quietly ignoring
> >           numerous fatal conditions. You should only consider disabling this
> >           option for embedded systems with no facilities for reporting errors.
> >           Just say Y.
> > 
> > will become completely misleading.  Turning this option off will _not_ 
> > result in "quietly ignoring numerous fatal conditions".
> 
> I'm fine with adding your text as a clarification - but I think 'quietly 
> ignoring fatal conditions' very much implies an undefined outcome if that 
> unexpected condition does occur: the code might crash, it might corrupt 
> memory or it might do some other unexpected thing.
> 
> There are many other places that do a BUG_ON() of a NULL pointer or so, or 
> of a zero refcount, or a not held lock - and turning the BUG_ON() off 
> makes the code unpredictable _anyway_ - even if the compiler does not 
> notice an uninitialized variable.
> 
> So pretty much any weakening of BUG_ON() _will_ make the kernel more 
> unpredictable.

FWIW, I've run some size analyis using the ARM 'multi_v7_defconfig'
and gcc-4.8, using various definitions for BUG() and BUG_ON(), to
see how big the size improvement actually gets

1. Baseline: normal bug plus CONFIG_BUG_VERBOSE
   text    data     bss     dec     hex filename
3743196  224396  206812 4174404  3fb244 vmlinux-bugverbose

2. disabling CONFIG_BUG_VERBOSE, saving 0.6%
3716920  224380  206812 4148112  3f4b90 vmlinux-nobugverbose

3. #define BUG() panic(__func__), #define BUG_ON(c) if(c) BUG(), saving 1.0%
3701076  224384  206812 4132272  3f0db0 vmlinux-bug-panicfunc

3. #define BUG() panic(__func__), #define BUG_ON(c) if(c) BUG(), saving 1.5%
3678884  224400  206812 4110096  3eb710 vmlinux-bug-panic

4. #define BUG() unreachable(), saving 2.1%
3652636  224384  206812 4083832  3e5078 vmlinux-bug-unreachable

5. as 4, plus #define BUG_ON(c) if(c) unreachable(), saving 2.2%
3651108  224380  206812 4082300  3e4a7c vmlinux-bugon-unreachable

6. #define BUG() do{}while(0), saving 2.1%
3654264  224380  206812 4085456  3e56d0 vmlinux-nobug

7. as 6, plus #define BUG_ON if(0 && (c)) unreachable, saving 2.2%
3648392  223996  206748 4079136  3e3e20 vmlinux-no-bugon

8. my patch below, saving 1.8%
3666532  224380  206812 4097724  3e86bc obj-tmp/vmlinux

The gain of doing unreachable and letting the code run off whereever
is minimal compared to the current state of doing nothing, but it
avoids the warnings.

Same test using x86_defconfig:

1. CONFIG_BUG=y, CONFIG_BUGVERBOSE=n
10797859        1395648 1175552 13369059         cbfee3 vmlinux-x86-bug

2. CONFIG_BUG=n, saves 1.0%
10658553        1395584 1175552 13229689         c9de79 vmlinux-x86-nobug

3. with my patch, saves 0.8%
10684186        1395584 1175552 13255322         ca429a vmlinux-x86-archbug

Getting 1-2% savings in kernel size seems absolutely worth keeping the
option, but 0.2-0.4% left for getting reproducible behavior also seems
worthwhile. The result in the patch below.

This basically loses any of the BUG() reporting, but leaves the
logic to trap and kill the task in place when CONFIG_BUG is disabled.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>

diff --git a/arch/arm/include/asm/bug.h b/arch/arm/include/asm/bug.h
index 7af5c6c..f25e638 100644
--- a/arch/arm/include/asm/bug.h
+++ b/arch/arm/include/asm/bug.h
@@ -3,8 +3,6 @@
 
 #include <linux/linkage.h>
 
-#ifdef CONFIG_BUG
-
 /*
  * Use a suitable undefined instruction to use for ARM/Thumb2 bug handling.
  * We need to be careful not to conflict with those used by other modules and
@@ -51,10 +50,10 @@ do {								\
 	asm volatile(BUG_INSTR_TYPE #__value);			\
 	unreachable();						\
 } while (0)
 #endif  /* CONFIG_DEBUG_BUGVERBOSE */
 
 #define HAVE_ARCH_BUG
-#endif  /* CONFIG_BUG */
+#define HAVE_ARCH_BUG_ON
 
 #include <asm-generic/bug.h>
 
diff --git a/arch/x86/include/asm/bug.h b/arch/x86/include/asm/bug.h
index 2f03ff0..ba38ebb 100644
--- a/arch/x86/include/asm/bug.h
+++ b/arch/x86/include/asm/bug.h
@@ -1,7 +1,6 @@
 #ifndef _ASM_X86_BUG_H
 #define _ASM_X86_BUG_H
 
-#ifdef CONFIG_BUG
 #define HAVE_ARCH_BUG
 
 #ifdef CONFIG_DEBUG_BUGVERBOSE
@@ -33,8 +32,6 @@ do {								\
 } while (0)
 #endif
 
-#endif /* !CONFIG_BUG */
-
 #include <asm-generic/bug.h>
 
 #endif /* _ASM_X86_BUG_H */
diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
index 7d10f96..bbd2872 100644
--- a/include/asm-generic/bug.h
+++ b/include/asm-generic/bug.h
@@ -112,12 +112,13 @@ extern void warn_slowpath_null(const char *file, const int line);
 #endif
 
 #ifndef HAVE_ARCH_BUG_ON
-#define BUG_ON(condition) do { if (condition) ; } while(0)
+#define BUG_ON(condition) do { if (unlikely(condition)) BUG(); } while(0)
 #endif
 
 #ifndef HAVE_ARCH_WARN_ON
 #define WARN_ON(condition) ({						\
 	int __ret_warn_on = !!(condition);				\
+	(void)__ret_warn_on;						\
 	unlikely(__ret_warn_on);					\
 })
 #endif
@@ -125,6 +126,8 @@ extern void warn_slowpath_null(const char *file, const int line);
 #ifndef WARN
 #define WARN(condition, format...) ({					\
 	int __ret_warn_on = !!(condition);				\
+	if (0 && (__ret_warn_on))					\
+		printk(format);						\
 	unlikely(__ret_warn_on);					\
 })
 #endif

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Arnd Bergmann]

On Tuesday 28 May 2013 10:19:10 Ingo Molnar wrote:
> 
> * Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> 
> > So, if you want to use this, then you should update the CONFIG_BUG text 
> > to include a warning to this effect:
> > 
> >      Warning: if CONFIG_BUG is turned off, and control flow reaches
> >      a BUG(), the system behaviour will be undefined.
> > 
> > so that people can make an informed choice about this, because at the
> > moment:
> > 
> >           Disabling this option eliminates support for BUG and WARN, reducing
> >           the size of your kernel image and potentially quietly ignoring
> >           numerous fatal conditions. You should only consider disabling this
> >           option for embedded systems with no facilities for reporting errors.
> >           Just say Y.
> > 
> > will become completely misleading.  Turning this option off will _not_ 
> > result in "quietly ignoring numerous fatal conditions".
> 
> I'm fine with adding your text as a clarification - but I think 'quietly 
> ignoring fatal conditions' very much implies an undefined outcome if that 
> unexpected condition does occur: the code might crash, it might corrupt 
> memory or it might do some other unexpected thing.
> 
> There are many other places that do a BUG_ON() of a NULL pointer or so, or 
> of a zero refcount, or a not held lock - and turning the BUG_ON() off 
> makes the code unpredictable _anyway_ - even if the compiler does not 
> notice an uninitialized variable.
> 
> So pretty much any weakening of BUG_ON() _will_ make the kernel more 
> unpredictable.

FWIW, I've run some size analyis using the ARM 'multi_v7_defconfig'
and gcc-4.8, using various definitions for BUG() and BUG_ON(), to
see how big the size improvement actually gets

1. Baseline: normal bug plus CONFIG_BUG_VERBOSE
   text    data     bss     dec     hex filename
3743196  224396  206812 4174404  3fb244 vmlinux-bugverbose

2. disabling CONFIG_BUG_VERBOSE, saving 0.6%
3716920  224380  206812 4148112  3f4b90 vmlinux-nobugverbose

3. #define BUG() panic(__func__), #define BUG_ON(c) if(c) BUG(), saving 1.0%
3701076  224384  206812 4132272  3f0db0 vmlinux-bug-panicfunc

3. #define BUG() panic(__func__), #define BUG_ON(c) if(c) BUG(), saving 1.5%
3678884  224400  206812 4110096  3eb710 vmlinux-bug-panic

4. #define BUG() unreachable(), saving 2.1%
3652636  224384  206812 4083832  3e5078 vmlinux-bug-unreachable

5. as 4, plus #define BUG_ON(c) if(c) unreachable(), saving 2.2%
3651108  224380  206812 4082300  3e4a7c vmlinux-bugon-unreachable

6. #define BUG() do{}while(0), saving 2.1%
3654264  224380  206812 4085456  3e56d0 vmlinux-nobug

7. as 6, plus #define BUG_ON if(0 && (c)) unreachable, saving 2.2%
3648392  223996  206748 4079136  3e3e20 vmlinux-no-bugon

8. my patch below, saving 1.8%
3666532  224380  206812 4097724  3e86bc obj-tmp/vmlinux

The gain of doing unreachable and letting the code run off whereever
is minimal compared to the current state of doing nothing, but it
avoids the warnings.

Same test using x86_defconfig:

1. CONFIG_BUG=y, CONFIG_BUGVERBOSE=n
10797859        1395648 1175552 13369059         cbfee3 vmlinux-x86-bug

2. CONFIG_BUG=n, saves 1.0%
10658553        1395584 1175552 13229689         c9de79 vmlinux-x86-nobug

3. with my patch, saves 0.8%
10684186        1395584 1175552 13255322         ca429a vmlinux-x86-archbug

Getting 1-2% savings in kernel size seems absolutely worth keeping the
option, but 0.2-0.4% left for getting reproducible behavior also seems
worthwhile. The result in the patch below.

This basically loses any of the BUG() reporting, but leaves the
logic to trap and kill the task in place when CONFIG_BUG is disabled.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>

diff --git a/arch/arm/include/asm/bug.h b/arch/arm/include/asm/bug.h
index 7af5c6c..f25e638 100644
--- a/arch/arm/include/asm/bug.h
+++ b/arch/arm/include/asm/bug.h
@@ -3,8 +3,6 @@
 
 #include <linux/linkage.h>
 
-#ifdef CONFIG_BUG
-
 /*
  * Use a suitable undefined instruction to use for ARM/Thumb2 bug handling.
  * We need to be careful not to conflict with those used by other modules and
@@ -51,10 +50,10 @@ do {								\
 	asm volatile(BUG_INSTR_TYPE #__value);			\
 	unreachable();						\
 } while (0)
 #endif  /* CONFIG_DEBUG_BUGVERBOSE */
 
 #define HAVE_ARCH_BUG
-#endif  /* CONFIG_BUG */
+#define HAVE_ARCH_BUG_ON
 
 #include <asm-generic/bug.h>
 
diff --git a/arch/x86/include/asm/bug.h b/arch/x86/include/asm/bug.h
index 2f03ff0..ba38ebb 100644
--- a/arch/x86/include/asm/bug.h
+++ b/arch/x86/include/asm/bug.h
@@ -1,7 +1,6 @@
 #ifndef _ASM_X86_BUG_H
 #define _ASM_X86_BUG_H
 
-#ifdef CONFIG_BUG
 #define HAVE_ARCH_BUG
 
 #ifdef CONFIG_DEBUG_BUGVERBOSE
@@ -33,8 +32,6 @@ do {								\
 } while (0)
 #endif
 
-#endif /* !CONFIG_BUG */
-
 #include <asm-generic/bug.h>
 
 #endif /* _ASM_X86_BUG_H */
diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
index 7d10f96..bbd2872 100644
--- a/include/asm-generic/bug.h
+++ b/include/asm-generic/bug.h
@@ -112,12 +112,13 @@ extern void warn_slowpath_null(const char *file, const int line);
 #endif
 
 #ifndef HAVE_ARCH_BUG_ON
-#define BUG_ON(condition) do { if (condition) ; } while(0)
+#define BUG_ON(condition) do { if (unlikely(condition)) BUG(); } while(0)
 #endif
 
 #ifndef HAVE_ARCH_WARN_ON
 #define WARN_ON(condition) ({						\
 	int __ret_warn_on = !!(condition);				\
+	(void)__ret_warn_on;						\
 	unlikely(__ret_warn_on);					\
 })
 #endif
@@ -125,6 +126,8 @@ extern void warn_slowpath_null(const char *file, const int line);
 #ifndef WARN
 #define WARN(condition, format...) ({					\
 	int __ret_warn_on = !!(condition);				\
+	if (0 && (__ret_warn_on))					\
+		printk(format);						\
 	unlikely(__ret_warn_on);					\
 })
 #endif

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[H. Peter Anvin]

On 05/28/2013 01:19 AM, Ingo Molnar wrote:
> 
> So I think the same principle applies to it as to any other debugging 
> code: it's fine to be able to turn debugging off. It's a performance 
> versus kernel robustness/determinism trade-off.
> 

I suspect, rather, that BUG() should turn into a trap (or jump to a
death routine) under any circumstances.  The one thing that can be
omitted for small configurations are the annotations, which only serve
to output a more human-readable error message.

	-hpa

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[H. Peter Anvin]

On 05/28/2013 01:19 AM, Ingo Molnar wrote:
> 
> So I think the same principle applies to it as to any other debugging 
> code: it's fine to be able to turn debugging off. It's a performance 
> versus kernel robustness/determinism trade-off.
> 

I suspect, rather, that BUG() should turn into a trap (or jump to a
death routine) under any circumstances.  The one thing that can be
omitted for small configurations are the annotations, which only serve
to output a more human-readable error message.

	-hpa

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[H. Peter Anvin]

On 05/28/2013 01:19 AM, Ingo Molnar wrote:
> 
> So I think the same principle applies to it as to any other debugging 
> code: it's fine to be able to turn debugging off. It's a performance 
> versus kernel robustness/determinism trade-off.
> 

I suspect, rather, that BUG() should turn into a trap (or jump to a
death routine) under any circumstances.  The one thing that can be
omitted for small configurations are the annotations, which only serve
to output a more human-readable error message.

	-hpa

[PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[H. Peter Anvin]

On 05/28/2013 01:19 AM, Ingo Molnar wrote:
> 
> So I think the same principle applies to it as to any other debugging 
> code: it's fine to be able to turn debugging off. It's a performance 
> versus kernel robustness/determinism trade-off.
> 

I suspect, rather, that BUG() should turn into a trap (or jump to a
death routine) under any circumstances.  The one thing that can be
omitted for small configurations are the annotations, which only serve
to output a more human-readable error message.

	-hpa

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[H. Peter Anvin]

On 05/28/2013 01:19 AM, Ingo Molnar wrote:
> 
> So I think the same principle applies to it as to any other debugging 
> code: it's fine to be able to turn debugging off. It's a performance 
> versus kernel robustness/determinism trade-off.
> 

I suspect, rather, that BUG() should turn into a trap (or jump to a
death routine) under any circumstances.  The one thing that can be
omitted for small configurations are the annotations, which only serve
to output a more human-readable error message.

	-hpa

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Arnd Bergmann]

On Tuesday 28 May 2013, H. Peter Anvin wrote:
> On 05/28/2013 01:19 AM, Ingo Molnar wrote:
> > 
> > So I think the same principle applies to it as to any other debugging 
> > code: it's fine to be able to turn debugging off. It's a performance 
> > versus kernel robustness/determinism trade-off.
> > 
> 
> I suspect, rather, that BUG() should turn into a trap (or jump to a
> death routine) under any circumstances.  The one thing that can be
> omitted for small configurations are the annotations, which only serve
> to output a more human-readable error message.

Right, that is what the patch I just posted does.

On a related note, I found that WARN_ON() can no longer be compiled
out since there is already code that relies on the side-effects of
the condition. I assume that was an intentional change I missed,
since it used to be defined so that you could remove it completely.

	Arnd

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Arnd Bergmann]

On Tuesday 28 May 2013, H. Peter Anvin wrote:
> On 05/28/2013 01:19 AM, Ingo Molnar wrote:
> > 
> > So I think the same principle applies to it as to any other debugging 
> > code: it's fine to be able to turn debugging off. It's a performance 
> > versus kernel robustness/determinism trade-off.
> > 
> 
> I suspect, rather, that BUG() should turn into a trap (or jump to a
> death routine) under any circumstances.  The one thing that can be
> omitted for small configurations are the annotations, which only serve
> to output a more human-readable error message.

Right, that is what the patch I just posted does.

On a related note, I found that WARN_ON() can no longer be compiled
out since there is already code that relies on the side-effects of
the condition. I assume that was an intentional change I missed,
since it used to be defined so that you could remove it completely.

	Arnd

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Arnd Bergmann]

On Tuesday 28 May 2013, H. Peter Anvin wrote:
> On 05/28/2013 01:19 AM, Ingo Molnar wrote:
> > 
> > So I think the same principle applies to it as to any other debugging 
> > code: it's fine to be able to turn debugging off. It's a performance 
> > versus kernel robustness/determinism trade-off.
> > 
> 
> I suspect, rather, that BUG() should turn into a trap (or jump to a
> death routine) under any circumstances.  The one thing that can be
> omitted for small configurations are the annotations, which only serve
> to output a more human-readable error message.

Right, that is what the patch I just posted does.

On a related note, I found that WARN_ON() can no longer be compiled
out since there is already code that relies on the side-effects of
the condition. I assume that was an intentional change I missed,
since it used to be defined so that you could remove it completely.

	Arnd

[PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Arnd Bergmann]

On Tuesday 28 May 2013, H. Peter Anvin wrote:
> On 05/28/2013 01:19 AM, Ingo Molnar wrote:
> > 
> > So I think the same principle applies to it as to any other debugging 
> > code: it's fine to be able to turn debugging off. It's a performance 
> > versus kernel robustness/determinism trade-off.
> > 
> 
> I suspect, rather, that BUG() should turn into a trap (or jump to a
> death routine) under any circumstances.  The one thing that can be
> omitted for small configurations are the annotations, which only serve
> to output a more human-readable error message.

Right, that is what the patch I just posted does.

On a related note, I found that WARN_ON() can no longer be compiled
out since there is already code that relies on the side-effects of
the condition. I assume that was an intentional change I missed,
since it used to be defined so that you could remove it completely.

	Arnd

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Arnd Bergmann]

On Tuesday 28 May 2013, H. Peter Anvin wrote:
> On 05/28/2013 01:19 AM, Ingo Molnar wrote:
> > 
> > So I think the same principle applies to it as to any other debugging 
> > code: it's fine to be able to turn debugging off. It's a performance 
> > versus kernel robustness/determinism trade-off.
> > 
> 
> I suspect, rather, that BUG() should turn into a trap (or jump to a
> death routine) under any circumstances.  The one thing that can be
> omitted for small configurations are the annotations, which only serve
> to output a more human-readable error message.

Right, that is what the patch I just posted does.

On a related note, I found that WARN_ON() can no longer be compiled
out since there is already code that relies on the side-effects of
the condition. I assume that was an intentional change I missed,
since it used to be defined so that you could remove it completely.

	Arnd

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[H. Peter Anvin]

On 05/28/2013 08:43 AM, Arnd Bergmann wrote:
> 
> Right, that is what the patch I just posted does.
> 
> On a related note, I found that WARN_ON() can no longer be compiled
> out since there is already code that relies on the side-effects of
> the condition. I assume that was an intentional change I missed,
> since it used to be defined so that you could remove it completely.
> 

It is possible to define WARN_ON() as:

#define WARN_ON(x) ((void)(x))

... which preserves side effects.

	-hpa

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[H. Peter Anvin]

On 05/28/2013 08:43 AM, Arnd Bergmann wrote:
> 
> Right, that is what the patch I just posted does.
> 
> On a related note, I found that WARN_ON() can no longer be compiled
> out since there is already code that relies on the side-effects of
> the condition. I assume that was an intentional change I missed,
> since it used to be defined so that you could remove it completely.
> 

It is possible to define WARN_ON() as:

#define WARN_ON(x) ((void)(x))

... which preserves side effects.

	-hpa

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[H. Peter Anvin]

On 05/28/2013 08:43 AM, Arnd Bergmann wrote:
> 
> Right, that is what the patch I just posted does.
> 
> On a related note, I found that WARN_ON() can no longer be compiled
> out since there is already code that relies on the side-effects of
> the condition. I assume that was an intentional change I missed,
> since it used to be defined so that you could remove it completely.
> 

It is possible to define WARN_ON() as:

#define WARN_ON(x) ((void)(x))

... which preserves side effects.

	-hpa

[PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[H. Peter Anvin]

On 05/28/2013 08:43 AM, Arnd Bergmann wrote:
> 
> Right, that is what the patch I just posted does.
> 
> On a related note, I found that WARN_ON() can no longer be compiled
> out since there is already code that relies on the side-effects of
> the condition. I assume that was an intentional change I missed,
> since it used to be defined so that you could remove it completely.
> 

It is possible to define WARN_ON() as:

#define WARN_ON(x) ((void)(x))

... which preserves side effects.

	-hpa

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[H. Peter Anvin]

On 05/28/2013 08:43 AM, Arnd Bergmann wrote:
> 
> Right, that is what the patch I just posted does.
> 
> On a related note, I found that WARN_ON() can no longer be compiled
> out since there is already code that relies on the side-effects of
> the condition. I assume that was an intentional change I missed,
> since it used to be defined so that you could remove it completely.
> 

It is possible to define WARN_ON() as:

#define WARN_ON(x) ((void)(x))

... which preserves side effects.

	-hpa

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Arnd Bergmann]

On Tuesday 28 May 2013, H. Peter Anvin wrote:
> On 05/28/2013 08:43 AM, Arnd Bergmann wrote:
> > 
> > Right, that is what the patch I just posted does.
> > 
> > On a related note, I found that WARN_ON() can no longer be compiled
> > out since there is already code that relies on the side-effects of
> > the condition. I assume that was an intentional change I missed,
> > since it used to be defined so that you could remove it completely.
> > 
> 
> It is possible to define WARN_ON() as:
> 
> #define WARN_ON(x) ((void)(x))
> 
> ... which preserves side effects.

Yes, actually the return value has to be maintained as well.
The current (!CONFIG_BUG) default implementation is

#define WARN_ON(condition) ({                                           \
        int __ret_warn_on = !!(condition);                              \
        unlikely(__ret_warn_on);                                        \
})

which seems fine.

#define WARN_ON(condition) unlikely(!!(condition))

is probably just as good.

	Arnd

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Arnd Bergmann]

On Tuesday 28 May 2013, H. Peter Anvin wrote:
> On 05/28/2013 08:43 AM, Arnd Bergmann wrote:
> > 
> > Right, that is what the patch I just posted does.
> > 
> > On a related note, I found that WARN_ON() can no longer be compiled
> > out since there is already code that relies on the side-effects of
> > the condition. I assume that was an intentional change I missed,
> > since it used to be defined so that you could remove it completely.
> > 
> 
> It is possible to define WARN_ON() as:
> 
> #define WARN_ON(x) ((void)(x))
> 
> ... which preserves side effects.

Yes, actually the return value has to be maintained as well.
The current (!CONFIG_BUG) default implementation is

#define WARN_ON(condition) ({                                           \
        int __ret_warn_on = !!(condition);                              \
        unlikely(__ret_warn_on);                                        \
})

which seems fine.

#define WARN_ON(condition) unlikely(!!(condition))

is probably just as good.

	Arnd

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Arnd Bergmann]

On Tuesday 28 May 2013, H. Peter Anvin wrote:
> On 05/28/2013 08:43 AM, Arnd Bergmann wrote:
> > 
> > Right, that is what the patch I just posted does.
> > 
> > On a related note, I found that WARN_ON() can no longer be compiled
> > out since there is already code that relies on the side-effects of
> > the condition. I assume that was an intentional change I missed,
> > since it used to be defined so that you could remove it completely.
> > 
> 
> It is possible to define WARN_ON() as:
> 
> #define WARN_ON(x) ((void)(x))
> 
> ... which preserves side effects.

Yes, actually the return value has to be maintained as well.
The current (!CONFIG_BUG) default implementation is

#define WARN_ON(condition) ({                                           \
        int __ret_warn_on = !!(condition);                              \
        unlikely(__ret_warn_on);                                        \
})

which seems fine.

#define WARN_ON(condition) unlikely(!!(condition))

is probably just as good.

	Arnd

[PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Arnd Bergmann]

On Tuesday 28 May 2013, H. Peter Anvin wrote:
> On 05/28/2013 08:43 AM, Arnd Bergmann wrote:
> > 
> > Right, that is what the patch I just posted does.
> > 
> > On a related note, I found that WARN_ON() can no longer be compiled
> > out since there is already code that relies on the side-effects of
> > the condition. I assume that was an intentional change I missed,
> > since it used to be defined so that you could remove it completely.
> > 
> 
> It is possible to define WARN_ON() as:
> 
> #define WARN_ON(x) ((void)(x))
> 
> ... which preserves side effects.

Yes, actually the return value has to be maintained as well.
The current (!CONFIG_BUG) default implementation is

#define WARN_ON(condition) ({                                           \
        int __ret_warn_on = !!(condition);                              \
        unlikely(__ret_warn_on);                                        \
})

which seems fine.

#define WARN_ON(condition) unlikely(!!(condition))

is probably just as good.

	Arnd

Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.

[Arnd Bergmann]

On Tuesday 28 May 2013, H. Peter Anvin wrote:
> On 05/28/2013 08:43 AM, Arnd Bergmann wrote:
> > 
> > Right, that is what the patch I just posted does.
> > 
> > On a related note, I found that WARN_ON() can no longer be compiled
> > out since there is already code that relies on the side-effects of
> > the condition. I assume that was an intentional change I missed,
> > since it used to be defined so that you could remove it completely.
> > 
> 
> It is possible to define WARN_ON() as:
> 
> #define WARN_ON(x) ((void)(x))
> 
> ... which preserves side effects.

Yes, actually the return value has to be maintained as well.
The current (!CONFIG_BUG) default implementation is

#define WARN_ON(condition) ({                                           \
        int __ret_warn_on = !!(condition);                              \
        unlikely(__ret_warn_on);                                        \
})

which seems fine.

#define WARN_ON(condition) unlikely(!!(condition))

is probably just as good.

	Arnd
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev