Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.
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
Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.
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 ___ 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.
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 ___ 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.
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 ___ 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.
On Tuesday 28 May 2013 10:19:10 Ingo Molnar wrote:
>
> * 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'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
textdata 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
107978591395648 1175552 13369059 cbfee3 vmlinux-x86-bug
2. CONFIG_BUG=n, saves 1.0%
106585531395584 1175552 13229689 c9de79 vmlinux-x86-nobug
3. with my patch, saves 0.8%
106841861395584 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
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
-#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
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
#endif /* _ASM_X86_BUG_H */
diff --git a/include/asm-generic/bug.h b/include/asm-ge
Re: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.
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 ___ 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.
* 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'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 ___ 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 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" ___ 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.
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
>> 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
> 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.
On 05/23/2013 10:10 PM, Geert Uytterhoeven wrote:
> On Thu, May 23, 2013 at 2:50 PM, Russell King - ARM Linux
> 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
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.
On Thu, May 23, 2013 at 2:50 PM, Russell King - ARM Linux
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 -- ge...@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
___
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.
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. ___ 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.
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 ___ 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.
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. ___ 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.
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 ___ 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.
Arnd Bergmann 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
>
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
___
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.
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.
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 ___ 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.
On Thu, May 23, 2013 at 03:09:50AM -0700, Eric W. Biederman wrote:
> Arnd Bergmann 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.
___
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.
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?
___
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.
On 05/23/2013 05:12 PM, Geert Uytterhoeven wrote:
> On Thu, May 23, 2013 at 11:05 AM, Russell King - ARM Linux
> 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 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
#include
#include
#include
#include
#include
#include
#include
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;
}
___
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.
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
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
___
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.
On Thu, May 23, 2013 at 11:05 AM, Russell King - ARM Linux
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 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 -- ge...@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
___
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.
On Thu, May 23, 2013 at 10:40:29AM +0200, Geert Uytterhoeven wrote: > On Thu, May 23, 2013 at 9:57 AM, Chen Gang 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. ___ 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.
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 ___ 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.
On Thu, May 23, 2013 at 9:57 AM, Chen Gang 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 -- ge...@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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.
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 --- 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
