[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201201140849.GH2767@kadam>
Date: Tue, 1 Dec 2020 17:08:49 +0300
From: Dan Carpenter <dan.carpenter@...cle.com>
To: Nick Desaulniers <ndesaulniers@...gle.com>
Cc: Kees Cook <keescook@...omium.org>, alsa-devel@...a-project.org,
linux-atm-general@...ts.sourceforge.net,
reiserfs-devel@...r.kernel.org, linux-iio@...r.kernel.org,
linux-wireless <linux-wireless@...r.kernel.org>,
linux-fbdev@...r.kernel.org,
dri-devel <dri-devel@...ts.freedesktop.org>,
LKML <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@...n.linbit.com,
devel@...verdev.osuosl.org, linux-cifs@...r.kernel.org,
rds-devel@....oracle.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 list <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>,
Jakub Kicinski <kuba@...nel.org>, linux-ext4@...r.kernel.org,
linux-media@...r.kernel.org, linux-watchdog@...r.kernel.org,
selinux@...r.kernel.org,
linux-arm-msm <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 <linux-arm-kernel@...ts.infradead.org>,
linux-hwmon@...r.kernel.org,
"maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@...nel.org>,
linux-nfs@...r.kernel.org, GR-Linux-NIC-Dev@...vell.com,
tipc-discussion@...ts.sourceforge.net,
Linux Memory Management List <linux-mm@...ck.org>,
Network Development <netdev@...r.kernel.org>,
linux-decnet-user@...ts.sourceforge.net, linux-mmc@...r.kernel.org,
"Gustavo A. R. Silva" <gustavoars@...nel.org>,
Linux-Renesas <linux-renesas-soc@...r.kernel.org>,
linux-sctp@...r.kernel.org, linux-usb@...r.kernel.org,
netfilter-devel@...r.kernel.org,
"open list:HARDWARE RANDOM NUMBER GENERATOR CORE"
<linux-crypto@...r.kernel.org>, patches@...nsource.cirrus.com,
Joe Perches <joe@...ches.com>, linux-integrity@...r.kernel.org,
target-devel@...r.kernel.org, linux-hardening@...r.kernel.org
Subject: Re: [PATCH 000/141] Fix fall-through warnings for Clang
On Mon, Nov 23, 2020 at 05:32:51PM -0800, Nick Desaulniers wrote:
> On Sun, Nov 22, 2020 at 8:17 AM Kees Cook <keescook@...omium.org> wrote:
> >
> > On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > > If none of the 140 patches here fix a real bug, and there is no change
> > > to machine code then it sounds to me like a W=2 kind of a warning.
> >
> > FWIW, this series has found at least one bug so far:
> > https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/
>
> So looks like the bulk of these are:
> switch (x) {
> case 0:
> ++x;
> default:
> break;
> }
This should not generate a warning.
>
> I have a patch that fixes those up for clang:
> https://reviews.llvm.org/D91895
>
> There's 3 other cases that don't quite match between GCC and Clang I
> observe in the kernel:
> switch (x) {
> case 0:
> ++x;
> default:
> goto y;
> }
> y:;
This should generate a warning.
>
> switch (x) {
> case 0:
> ++x;
> default:
> return;
> }
Warn for this.
>
> switch (x) {
> case 0:
> ++x;
> default:
> ;
> }
Don't warn for this.
If adding a break statement changes the flow of the code then warn about
potentially missing break statements, but if it doesn't change anything
then don't warn about it.
regards,
dan carpenter
Powered by blists - more mailing lists