linux-kernel - Re: [PATCH 0/7] Silence even more W=2 warnings

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: <1411416573.2513.19.camel@jtkirshe-mobl.jf.intel.com>
Date:	Mon, 22 Sep 2014 13:09:33 -0700
From:	Jeff Kirsher <jeffrey.t.kirsher@...el.com>
To:	Borislav Petkov <bp@...en8.de>
Cc:	"Rustad, Mark D" <mark.d.rustad@...el.com>,
	"sparse@...isli.org" <sparse@...isli.org>,
	"linux-sparse@...r.kernel.org" <linux-sparse@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/7] Silence even more W=2 warnings

On Mon, 2014-09-22 at 21:57 +0200, Borislav Petkov wrote:
> On Mon, Sep 22, 2014 at 12:44:17PM -0700, Jeff Kirsher wrote:
> > Not sure you showed us, since that is how everyone has had to do to
> > actual find W= builds useful.  Just because that is how we HAVE to
> do it
> > now, does not make it the best way.  Here is a thought, we don't we
> fix
> > the potential issues, so that W= builds do not generate over 100,000
> > errors/warnings.
> > 
> > Mark did this approach because it would either spur the conversation
> > that this is a good idea OR let's fix the root problem.  Instead it
> > sounds like your response is "life sucks, get over it" and put your
> head
> > back in the sand to ignore the problem.
> 
> Hey hey, relax a little - no need to get offensive all of a sudden.

Sorry I am very frustrated at your response.
> 
> Having to grep through a log file full of gcc warnings is a much
> better
> thing to do IMNSVHO than adding code to the kernel just to shut up the
> compiler. We had huge discussions even about something as silly as
> uninitialized_var() which was supposed to shut up the compiler but
> ended
> up actively causing bugs.

I am not saying that the proposed added MACRO is the best solution to
this issue.  Several other maintainers have actually responded in a
similar manner to the macros being added and came back that the better
solution would be to fix the code so that the warnings do not occur in
the first place.

So I guess I was hoping for more of the response, that "let's fix this
the code so that the warnings do not appear in the first place".

I agree with you completely that I do not like the idea of the MACROS
being added to silence these warnings.  I just disagree that not doing
anything to fix the warnings is far worse.

Why grep through 100,000 warnings, when we should be fixing the code to
prevent 100,000 warnings.  Not saying that the MACRO is the best
solution, it is just a solution, in hopes that it spurs discussions like
this on how to properly fix the warnings.  Not a discussion on how to
grep through the warnings and do nothing.

> 
> Now, you're arguing for adding obscure macros to shut up warnings
> which
> are disabled in the first place because you don't want to grep through
> log files.
> 
> If you can't see the absurdity of your proposal then maybe we should
> agree to disagree and declare this back-and-forth for having run its
> course. In any case, you get my NAK for it.

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)