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: <20180925085558.GA22609@kroah.com>
Date:   Tue, 25 Sep 2018 10:55:58 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Sasha Levin <Alexander.Levin@...rosoft.com>
Cc:     Joe Perches <joe@...ches.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>,
        Bart Van Assche <bart.vanassche@....com>,
        Jason Gunthorpe <jgg@...lanox.com>
Subject: Re: [PATCH 3.18 104/105] IB/nes: Fix a compiler warning

On Mon, Sep 24, 2018 at 10:39:53PM +0000, Sasha Levin wrote:
> On Mon, Sep 24, 2018 at 11:03:25AM -0700, Joe Perches wrote:
> >On Mon, 2018-09-24 at 19:59 +0200, Greg Kroah-Hartman wrote:
> >> On Mon, Sep 24, 2018 at 09:38:26AM -0700, Joe Perches wrote:
> >> > On Mon, 2018-09-24 at 13:34 +0200, Greg Kroah-Hartman wrote:
> >> > > 3.18-stable review patch.  If anyone has any objections, please let me know.
> >> >
> >> > Why should this sort of change be applied to a stable release?
> >>
> >> Originally I was just going to drop this as it's not fixing something.
> >>
> >> But it might be, if that macro is used in a if() statement, or something
> >> like that, it could be doing something unintended.
> >
> >No it couldn't.
> >An empty macro is equivalent to a single statement.
> >
> >> So I don't feel like auditing all 500+ instances where this is used,
> >> it's easier to just accept the patch.
> >
> >It's not a bug fix.
> 
> This question came up a few months ago. Greg suggested that we should be
> pulling in warning fixes to get the stable kernels warning-free similar
> to upstream.
> 
> The reasoning behind it was similar to the "no warnings" reasoning of
> upstream: there might be real issues hiding in the sea of "harmless"
> warnings, so we want to get rid of all of them to catch real issues.

No warnings is great, but not when you add the "W=1" option.  That way
lies madness and is not something anyone does on stable kernels.  They
do it on mainline when they want to try to find something to clean up
and get a coding style fix merged :)

thanks,

greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ