[x86] BUG()/BUG_ON() macros cannot be disabled

[x86] BUG()/BUG_ON() macros cannot be disabled

[Alexander Lochmann]

[-- Attachment #1.1.1: Type: text/plain, Size: 975 bytes --]

Hi Arnd,

I recently tried to disable the BUG macros on x86-32. I disabled the
config item in 'General Setup -> Configure standard kernel features
(expert users) -> BUG() support'.
However, BUG/BUG_ON is still defined. In the !CONFIG_BUG branch in
include/asm-generic/bug.h (line 181) the code checks for the existence
of architecture-specific variants of those macros.
Since x86 defines its own version of BUG(), line 182 is *not* used.
In the following, the x86 variant of BUG() is then used to define the
BUG_ON() macro.

I propose a patch that really disables both macros if the developer
wants it.
It undefines the respective x86 variants, and defines both macros as
'empty' macros.

Regards,
Alex

-- 
Technische Universität Dortmund
Alexander Lochmann                PGP key: 0xBC3EF6FD
Otto-Hahn-Str. 16                 phone:  +49.231.7556141
D-44227 Dortmund                  fax:    +49.231.7556116
http://ess.cs.tu-dortmund.de/Staff/al

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.1.2: disable-bug-macro.patch --]
[-- Type: text/x-patch; name="disable-bug-macro.patch", Size: 766 bytes --]

diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
index 20561a60db9c..1e7977582277 100644
--- a/include/asm-generic/bug.h
+++ b/include/asm-generic/bug.h
@@ -178,14 +178,17 @@ void __warn(const char *file, int line, void *caller, unsigned taint,
 })
 
 #else /* !CONFIG_BUG */
-#ifndef HAVE_ARCH_BUG
-#define BUG() do {} while (1)
+#ifdef HAVE_ARCH_BUG
+#undef BUG
 #endif
 
-#ifndef HAVE_ARCH_BUG_ON
-#define BUG_ON(condition) do { if (condition) BUG(); } while (0)
+#ifdef HAVE_ARCH_BUG_ON
+#undef BUG_ON
 #endif
 
+#define BUG_ON(condition) do { if (condition) BUG(); } while (0)
+#define BUG() do {} while (1)
+
 #ifndef HAVE_ARCH_WARN_ON
 #define WARN_ON(condition) ({						\
 	int __ret_warn_on = !!(condition);				\

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [x86] BUG()/BUG_ON() macros cannot be disabled

[Arnd Bergmann]

On Tue, Sep 25, 2018 at 1:35 PM Alexander Lochmann
<alexander.lochmann@tu-dortmund.de> wrote:
>
> Hi Arnd,
>
> I recently tried to disable the BUG macros on x86-32. I disabled the
> config item in 'General Setup -> Configure standard kernel features
> (expert users) -> BUG() support'.
> However, BUG/BUG_ON is still defined. In the !CONFIG_BUG branch in
> include/asm-generic/bug.h (line 181) the code checks for the existence
> of architecture-specific variants of those macros.
> Since x86 defines its own version of BUG(), line 182 is *not* used.
> In the following, the x86 variant of BUG() is then used to define the
> BUG_ON() macro.
>
> I propose a patch that really disables both macros if the developer
> wants it.
> It undefines the respective x86 variants, and defines both macros as
> 'empty' macros.

Maybe we should update the documentation instead. Note that the
generic version is using 'while (1)' rather than 'while (0)', so this is
not an empty macro but rather one that does more than the
arch-specific one-instruction version does.

We don't really want an empty macro any more, this was used in
the past, but causes compile-time warnings and undefined behavior
for no good reason.

       Arnd

Re: [x86] BUG()/BUG_ON() macros cannot be disabled

[Alexander Lochmann]

[-- Attachment #1.1: Type: text/plain, Size: 1826 bytes --]



Am 25.09.2018 um 14:06 schrieb Arnd Bergmann:
> On Tue, Sep 25, 2018 at 1:35 PM Alexander Lochmann
> <alexander.lochmann@tu-dortmund.de> wrote:
>>
>> Hi Arnd,
>>
>> I recently tried to disable the BUG macros on x86-32. I disabled the
>> config item in 'General Setup -> Configure standard kernel features
>> (expert users) -> BUG() support'.
>> However, BUG/BUG_ON is still defined. In the !CONFIG_BUG branch in
>> include/asm-generic/bug.h (line 181) the code checks for the existence
>> of architecture-specific variants of those macros.
>> Since x86 defines its own version of BUG(), line 182 is *not* used.
>> In the following, the x86 variant of BUG() is then used to define the
>> BUG_ON() macro.
>>
>> I propose a patch that really disables both macros if the developer
>> wants it.
>> It undefines the respective x86 variants, and defines both macros as
>> 'empty' macros.
> 
> Maybe we should update the documentation instead. Note that the
> generic version is using 'while (1)' rather than 'while (0)', so this is
> not an empty macro but rather one that does more than the
> arch-specific one-instruction version does.
> 
> We don't really want an empty macro any more, this was used in
> the past, but causes compile-time warnings and undefined behavior
> for no good reason
I see. So the documentation of the CONFIG_BUG option is wrong?
It currently states that 'Disabling this option eliminates support for
BUG and WARN'.
Is the current implemention (an endless loop) desired behavior?

- Alex
> 
>        Arnd
> 

-- 
Technische Universität Dortmund
Alexander Lochmann                PGP key: 0xBC3EF6FD
Otto-Hahn-Str. 16                 phone:  +49.231.7556141
D-44227 Dortmund                  fax:    +49.231.7556116
http://ess.cs.tu-dortmund.de/Staff/al


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [x86] BUG()/BUG_ON() macros cannot be disabled

[Arnd Bergmann]

On Tue, Sep 25, 2018 at 2:13 PM Alexander Lochmann
<alexander.lochmann@tu-dortmund.de> wrote:
>
>
>
> Am 25.09.2018 um 14:06 schrieb Arnd Bergmann:
> > On Tue, Sep 25, 2018 at 1:35 PM Alexander Lochmann
> > <alexander.lochmann@tu-dortmund.de> wrote:
> >>
> >> Hi Arnd,
> >>
> >> I recently tried to disable the BUG macros on x86-32. I disabled the
> >> config item in 'General Setup -> Configure standard kernel features
> >> (expert users) -> BUG() support'.
> >> However, BUG/BUG_ON is still defined. In the !CONFIG_BUG branch in
> >> include/asm-generic/bug.h (line 181) the code checks for the existence
> >> of architecture-specific variants of those macros.
> >> Since x86 defines its own version of BUG(), line 182 is *not* used.
> >> In the following, the x86 variant of BUG() is then used to define the
> >> BUG_ON() macro.
> >>
> >> I propose a patch that really disables both macros if the developer
> >> wants it.
> >> It undefines the respective x86 variants, and defines both macros as
> >> 'empty' macros.
> >
> > Maybe we should update the documentation instead. Note that the
> > generic version is using 'while (1)' rather than 'while (0)', so this is
> > not an empty macro but rather one that does more than the
> > arch-specific one-instruction version does.
> >
> > We don't really want an empty macro any more, this was used in
> > the past, but causes compile-time warnings and undefined behavior
> > for no good reason
> I see. So the documentation of the CONFIG_BUG option is wrong?
> It currently states that 'Disabling this option eliminates support for
> BUG and WARN'.
> Is the current implemention (an endless loop) desired behavior?

I think it's the most reasonable implementation, otherwise a
function like

int something(void)
{
      if (x)
         return 0;
     else
          BUG();
}

will return an uninitialized value.

The arch specific implementations usually just contain a trapping
instruction. With CONFIG_BUG() you get a nice console output
that indicates where this happened, but without CONFIG_BUG(),
this is just reported as an invalid instruction (if CONFIG_PRINTK
is still enabled), killing the current process.

       Arnd

Re: [x86] BUG()/BUG_ON() macros cannot be disabled

[Alexander Stein]

Hello Arnd,

On Tuesday, September 25, 2018, 2:06:38 PM CEST Arnd Bergmann wrote:
> We don't really want an empty macro any more, this was used in
> the past, but causes compile-time warnings and undefined behavior
> for no good reason.

Can you elaborate or point me to some other discussion about that undefined behavior?

Best regards,
Alexander

Re: [x86] BUG()/BUG_ON() macros cannot be disabled

[Alexander Lochmann]

[-- Attachment #1.1: Type: text/plain, Size: 1325 bytes --]



Am 25.09.2018 um 14:20 schrieb Arnd Bergmann:
> 
> I think it's the most reasonable implementation, otherwise a
> function like
> 
> int something(void)
> {
>       if (x)
>          return 0;
>      else
>           BUG();
> }
> 
> will return an uninitialized value.
> 
> The arch specific implementations usually just contain a trapping
> instruction. With CONFIG_BUG() you get a nice console output
> that indicates where this happened, but without CONFIG_BUG(),
> this is just reported as an invalid instruction (if CONFIG_PRINTK
> is still enabled), killing the current process.
> 
>        Arnd
> 
I see. In that case, you should really update the documentation and help
page of CONFIG_BUG. In its current version it is misleading. It can be
understood as 'It disables that macro completely.'.

Although I know what the purpose of BUG()/BUG_ON() is, I would not
consider the above example as valid C code....
Defining BUG as an endless loop to overcome GCC warnings about not
returning a value is a dirty hack for me.

- Alex

-- 
Technische Universität Dortmund
Alexander Lochmann                PGP key: 0xBC3EF6FD
Otto-Hahn-Str. 16                 phone:  +49.231.7556141
D-44227 Dortmund                  fax:    +49.231.7556116
http://ess.cs.tu-dortmund.de/Staff/al


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]