linux-kernel - Re: [PATCH] linux/bits.h: fix -Wtype-limits warnings in GENMASK_INPUT

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: <20220307105810.1747024-1-alexandr.lobakin@intel.com>
Date:   Mon,  7 Mar 2022 11:58:10 +0100
From:   Alexander Lobakin <alexandr.lobakin@...el.com>
To:     Andy Shevchenko <andy.shevchenko@...il.com>
Cc:     Alexander Lobakin <alexandr.lobakin@...el.com>,
        Vincent Mailhol <mailhol.vincent@...adoo.fr>,
        Rikard Falkeborn <rikard.falkeborn@...il.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Arnd Bergmann <arnd@...db.de>,
        Kees Cook <keescook@...omium.org>
Subject: Re: [PATCH] linux/bits.h: fix -Wtype-limits warnings in GENMASK_INPUT_CHECK()

From: Andy Shevchenko <andy.shevchenko@...il.com>
Date: Fri, 4 Mar 2022 20:46:08 +0200

> On Fri, Mar 4, 2022 at 7:36 PM Vincent Mailhol
> <mailhol.vincent@...adoo.fr> wrote:
> >
> 
> > This pattern is harmless but because it occurs in header files
> > (example find_first_bit() from linux/find.h [1]) and because of the
> > include hell, the macro GENMASK_INPUT_CHECK() is accountable for 31%
> > (164714/532484) of all warnings when compiling all modules at W=2
> > level.

Nice catch, thanks! I wanted to submit the very same fix, but
postponed it for some reason, and now here we are.

> 
> Have you fixed W=1 warnings?
> Without fixing W=1 (which makes much more sense, when used with
> WERROR=y && COMPILE_TEST=y) this has no value.

How is this connected?
When I do `make W=2 path/to/my/code`, I want to see the actual code
problems, not something that comes from the include files.
When I do `make W=2 path/to/new/code/from/lkml`, I want to see the
actual new warnings, not something coming from the includes.
It's much easier to overlook or miss some real warnings when the
stderr is being flooded by the warnings from the include files.
I'm aware there are some scripts to compare before/after, but I
don't want to use them just because "this has to value".
I don't want to do `make W=2 KCFLAGS='-Wno-shadow -Wno-type-limits'`
because then I'm not able to spot the actual shadow or type limit
problems in my/new code.
I fixed several `-Wshadow` warnings previously in the include files
related to networking, and *nobody* said "this has no value" or
NAKed it. And `-Wshadow` has always been in W=2.

> 
> NAK.

...

> 
> -- 
> With Best Regards,
> Andy Shevchenko

Thanks,
Al