linux-kernel - Re: [PATCH 2/7] Compiler Attributes: use the no-underscores syntax

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANiq72m=AW_azRv+4HHoY7o-f1gSrmChB1XUfwkqz7hVJjU1cg@mail.gmail.com>
Date:   Mon, 3 Sep 2018 12:40:38 +0200
From:   Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:     Rasmus Villemoes <linux@...musvillemoes.dk>,
        "torvalds@...ux-foundation.org" <torvalds@...ux-foundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Eli Friedman <efriedma@...eaurora.org>,
        Christopher Li <sparse@...isli.org>,
        Kees Cook <keescook@...omium.org>,
        Ingo Molnar <mingo@...nel.org>, Arnd Bergmann <arnd@...db.de>,
        Greg KH <gregkh@...uxfoundation.org>,
        Masahiro Yamada <yamada.masahiro@...ionext.com>,
        Joe Perches <joe@...ches.com>,
        Dominique Martinet <asmadeus@...ewreck.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>
Subject: Re: [PATCH 2/7] Compiler Attributes: use the no-underscores syntax

Hi Geert,

On Mon, Sep 3, 2018 at 8:42 AM, Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
> Hi Miguel,
>
> On Sat, Sep 1, 2018 at 12:41 AM Miguel Ojeda
> <miguel.ojeda.sandonis@...il.com> wrote:
>> On Sat, Sep 1, 2018 at 12:10 AM, Miguel Ojeda
>> <miguel.ojeda.sandonis@...il.com> wrote:
>> > arch/parisc/boot/compressed/misc.c:#define malloc       malloc_gzip
>> > include/linux/decompress/mm.h:#define malloc(a) kmalloc(a, GFP_KERNEL)
>> > lib/inflate.c:#define malloc(a) kmalloc(a, GFP_KERNEL)
>> > include/linux/compiler_types.h:#define noinline_for_stack noinline
>> > include/linux/raid/pq.h:#define noinline __attribute__((noinline))
>> > tools/include/linux/compiler.h:#define noinline
>> > arch/mips/sgi-ip27/ip27-reset.c:#define noreturn while(1);
>>
>> A better list, searching for all attributes used anywhere in the kernel:
>>
>> git grep -E '^\s*#define\s+(address_space|alias|aligned|always_inline|assume_aligned|bitwise|bnd_legacy|cold|common|const|constructor|context|deprecated|designated_init|destructor|error|externally_visible|flatten|force|format|format|gnu_inline|hot|hotpatch|indirect_branch|latent_entropy|long_call|malloc|may_alias|mode|model|naked|nocast|noclone|noderef|noinline|no_instrument_function|nonnull|no_randomize_layout|noreturn|no_sanitize_address|optimize|packed|pure|randomize_layout|regparm|require_context|safe|section|syscall_linkage|target|tls_model|unused|used|user|vector_size|visibility|warning|warn_unused_result|weak)(\(|\s|$)'
>>
>> arch/mips/sgi-ip27/ip27-reset.c:#define noreturn while(1);
>>                  /* Silence gcc.  */
>> arch/parisc/boot/compressed/misc.c:#define malloc       malloc_gzip
>> arch/powerpc/xmon/ansidecl.h:#define    const
>> drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:#define error(fmt,
>> args...) bioslog(ERROR, fmt, ##args)
>> include/linux/compiler_attributes.h:#define   noinline
>> __attribute__((noinline))
>> include/linux/decompress/mm.h:#define malloc(a) kmalloc(a, GFP_KERNEL)
>> include/linux/raid/pq.h:#define noinline __attribute__((noinline))
>> lib/inflate.c:#define malloc(a) kmalloc(a, GFP_KERNEL)
>> tools/include/linux/compiler-gcc.h:#define  noinline
>> __attribute__((noinline))
>> tools/include/linux/compiler.h:#define noinline
>> tools/testing/selftests/futex/include/logging.h:#define error(message,
>> err, args...) \
>>
>> None of these should make a problem. And it would may avoid people
>> using such common-name-macros in the future ;-)
>
> That's very fragile.
> Who knows all (current and future) attribute names by heart, and that defining
> them could have such side effects?

Please see the email I sent after that one -- I clarified that this
was more about the current state and that in v3 it will be changed, if
only to avoid surprises in the future for ourselves. I agree with you
and, as Rasmus pointed out, we will use the macros anyway.

>
> At least "alias", "force", "format", "mode", "model", "optimize", "target" are
> names I wouldn't hesitate to use as a macro name in a driver...

A macro with a lowercase, short & common name is not the best idea in
my opinion; if only because of clarity for future readers. Unless it
really improved the code readability for some reason in a particular
case, I would avoid it. But to each his own! :-)

Thanks for reviewing!

Cheers,
Miguel