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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Mon, 29 Oct 2018 01:54:12 +0900
From:   Masahiro Yamada <yamada.masahiro@...ionext.com>
To:     David.Laight@...lab.com
Cc:     Borislav Petkov <bp@...en8.de>,
        Leonardo Brás <leobras.c@...il.com>,
        lkcamp@...ts.libreplanetbr.org,
        Matthew Wilcox <willy6545@...il.com>,
        Andy Lutomirski <luto@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>, X86 ML <x86@...nel.org>,
        Michal Marek <michal.lkml@...kovi.net>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>
Subject: Re: [PATCH 1/4] Adds -Wshadow=local on KBUILD_HOSTCFLAGS

On Fri, Oct 19, 2018 at 8:28 PM David Laight <David.Laight@...lab.com> wrote:
>
> From: Masahiro Yamada
> > Sent: 18 October 2018 17:39
> >
> > On Thu, Oct 18, 2018 at 6:18 PM Borislav Petkov <bp@...en8.de> wrote:
> > >
> > > On Wed, Oct 17, 2018 at 09:40:53PM -0300, Leonardo Bras wrote:
> > > > The idea was to put it as default and fix all the shadowing warnings.
> > > > What do you think?  I am open to suggestions.
> > >
> > > That's Masahiro's call. In the rest of the kernel, those warnings are behind
> > > the W=2 switch - i.e., not enabled by default.
> >
> >
> > It is not realistic to enable this warning option by default.
> > Even -Wshadow=local emits tons of warnings.
> > (More with -Wshadow)
>
> The question is, how many of them are actual bugs.
> IMHO -Wshadow is a good idea.
>
> > The problem of this flag is,
> > it is false positive in macro expansions.
>
> Right, but macro expansions inside macro definitions could accidentally
> use the same local variable - leading to choas.


I do not think so.

The macro definitions are surrounded by { ... }
so that local variables are properly separated from
the outside world.




> > For example, I think the following is a legitimate case.
> ...
> > arch/arm64/kernel/fpsimd.c:713:2: note: in expansion of macro ‘write_sysreg’
> >   write_sysreg(read_sysreg(CPACR_EL1) | CPACR_EL1_ZEN_EL1EN, CPACR_EL1);
> >   ^~~~~~~~~~~~
>
> Easily fixed by using different named temporaries in the two macros.
> There probably aren't that many macro pairs where that happens.
> Especially since many are now inlined functions.

But, theoretically, any arbitrary macros could be used in pairs.

This means a new constraint where a local variable name must be unique,
it means 'local variable' is not literally 'local'.


I'd like to use short names such as 'x', 'tmp', etc. for local variables.



> It might be that a small number of changes get rid of most of the warnings.
>
>         David
>
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
> Registration No: 1397386 (Wales)


--
Best Regards
Masahiro Yamada

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ