Message-ID: <20201123130348.GA3119@embeddedor>
Date:   Mon, 23 Nov 2020 07:03:48 -0600
From:   "Gustavo A. R. Silva" <gustavoars@...nel.org>
To:     James Bottomley <James.Bottomley@...senPartnership.com>
Cc:     Joe Perches <joe@...ches.com>, Kees Cook <keescook@...omium.org>,
        Jakub Kicinski <kuba@...nel.org>, alsa-devel@...a-project.org,
        linux-atm-general@...ts.sourceforge.net,
        reiserfs-devel@...r.kernel.org, linux-iio@...r.kernel.org,
        linux-wireless@...r.kernel.org, linux-fbdev@...r.kernel.org,
        dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
        Nathan Chancellor <natechancellor@...il.com>,
        linux-ide@...r.kernel.org, dm-devel@...hat.com,
        keyrings@...r.kernel.org, linux-mtd@...ts.infradead.org,
        GR-everest-linux-l2@...vell.com, wcn36xx@...ts.infradead.org,
        samba-technical@...ts.samba.org, linux-i3c@...ts.infradead.org,
        linux1394-devel@...ts.sourceforge.net,
        linux-afs@...ts.infradead.org,
        usb-storage@...ts.one-eyed-alien.net, drbd-dev@...ts.linbit.com,
        devel@...verdev.osuosl.org, linux-cifs@...r.kernel.org,
        rds-devel@....oracle.com,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        linux-scsi@...r.kernel.org, linux-rdma@...r.kernel.org,
        oss-drivers@...ronome.com, bridge@...ts.linux-foundation.org,
        linux-security-module@...r.kernel.org,
        amd-gfx@...ts.freedesktop.org,
        linux-stm32@...md-mailman.stormreply.com, cluster-devel@...hat.com,
        linux-acpi@...r.kernel.org, coreteam@...filter.org,
        intel-wired-lan@...ts.osuosl.org, linux-input@...r.kernel.org,
        Miguel Ojeda <ojeda@...nel.org>,
        tipc-discussion@...ts.sourceforge.net, linux-ext4@...r.kernel.org,
        linux-media@...r.kernel.org, linux-watchdog@...r.kernel.org,
        selinux@...r.kernel.org, linux-arm-msm@...r.kernel.org,
        intel-gfx@...ts.freedesktop.org, linux-geode@...ts.infradead.org,
        linux-can@...r.kernel.org, linux-block@...r.kernel.org,
        linux-gpio@...r.kernel.org, op-tee@...ts.trustedfirmware.org,
        linux-mediatek@...ts.infradead.org, xen-devel@...ts.xenproject.org,
        nouveau@...ts.freedesktop.org, linux-hams@...r.kernel.org,
        ceph-devel@...r.kernel.org,
        virtualization@...ts.linux-foundation.org,
        linux-arm-kernel@...ts.infradead.org, linux-hwmon@...r.kernel.org,
        x86@...nel.org, linux-nfs@...r.kernel.org,
        GR-Linux-NIC-Dev@...vell.com, linux-mm@...ck.org,
        netdev@...r.kernel.org, linux-decnet-user@...ts.sourceforge.net,
        linux-mmc@...r.kernel.org, linux-renesas-soc@...r.kernel.org,
        linux-sctp@...r.kernel.org, linux-usb@...r.kernel.org,
        netfilter-devel@...r.kernel.org, linux-crypto@...r.kernel.org,
        patches@...nsource.cirrus.com, linux-integrity@...r.kernel.org,
        target-devel@...r.kernel.org, linux-hardening@...r.kernel.org,
        Jonathan Cameron <Jonathan.Cameron@...wei.com>,
        Greg KH <gregkh@...uxfoundation.org>
Subject: Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for
 Clang

On Sun, Nov 22, 2020 at 11:53:55AM -0800, James Bottomley wrote:
> On Sun, 2020-11-22 at 11:22 -0800, Joe Perches wrote:
> > On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> > > On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> > > > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > > > > Please tell me our reward for all this effort isn't a single
> > > > > missing error print.
> > > > 
> > > > There were quite literally dozens of logical defects found
> > > > by the fallthrough additions.  Very few were logging only.
> > > 
> > > So can you give us the best examples (or indeed all of them if
> > > someone is keeping score)?  hopefully this isn't a US election
> > > situation ...
> > 
> > Gustavo?  Are you running for congress now?
> > 
> > https://lwn.net/Articles/794944/
> 
> That's 21 reported fixes of which about 50% seem to produce no change
> in code behaviour at all, a quarter seem to have no user visible effect
> with the remaining quarter producing unexpected errors on obscure
> configuration parameters, which is why no-one really noticed them
> before.

The really important point here is the number of bugs this has prevented
and will prevent in the future. See an example of this, below:

https://lore.kernel.org/linux-iio/20190813135802.GB27392@kroah.com/

This work is still relevant, even if the total number of issues/bugs
we find in the process is zero (which is not the case).

"The sucky thing about doing hard work to deploy hardening is that the
result is totally invisible by definition (things not happening) [..]"
- Dmitry Vyukov

Thanks
--
Gustavo

Powered by blists - more mailing lists