public inbox for linux-arm-kernel@lists.infradead.org 
 help / color / mirror / Atom feed
From: gang.chen@asianux•com (Chen Gang)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it.
Date: Fri, 24 May 2013 12:17:26 +0800	[thread overview]
Message-ID: <519EE9D6.9010707@asianux.com> (raw)
In-Reply-To: <519ECCCF.8090909@asianux.com>

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

  reply	other threads:[~2013-05-24  4:17 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-23  7:57 [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it Chen Gang
2013-05-23  8:40 ` Geert Uytterhoeven
2013-05-23  8:54   ` Arnd Bergmann
2013-05-23  9:05   ` Russell King - ARM Linux
2013-05-23  9:12     ` Geert Uytterhoeven
2013-05-23  9:39       ` Arnd Bergmann
2013-05-23 10:04         ` Russell King - ARM Linux
2013-05-23 10:41           ` Chen Gang
2013-05-23 10:59           ` Arnd Bergmann
2013-05-23 11:19             ` Chen Gang
2013-05-23 11:24             ` Russell King - ARM Linux
2013-05-23 12:09               ` Arnd Bergmann
2013-05-23 12:50                 ` Russell King - ARM Linux
2013-05-23 14:10                   ` Geert Uytterhoeven
2013-05-24  2:13                     ` Chen Gang
2013-05-24  4:17                       ` Chen Gang [this message]
2013-05-26  4:43                         ` [PATCH v2] arch: configuration issue, random return value when disable 'CONFIG_BUG' Chen Gang
2013-05-28  8:19           ` [PATCH] arch: configuration, deleting 'CONFIG_BUG' since always need it Ingo Molnar
2013-05-28 10:25             ` Chen Gang
2013-05-28 14:49             ` Arnd Bergmann
2013-05-28 14:55             ` H. Peter Anvin
2013-05-28 15:43               ` Arnd Bergmann
2013-05-28 16:06                 ` H. Peter Anvin
2013-05-28 17:20                   ` Arnd Bergmann
2013-05-23 10:09         ` Eric W. Biederman
2013-05-23 10:29           ` Russell King - ARM Linux
2013-05-23 10:05       ` Chen Gang
2013-05-24  5:59 ` Eric W. Biederman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=519EE9D6.9010707@asianux.com \
    --to=gang.chen@asianux$(echo .)com \
    --cc=linux-arm-kernel@lists$(echo .)infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox