[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 000/141] Fix fall-through warnings for Clang
- To: Nick Desaulniers <ndesaulniers@xxxxxxxxxx>
- From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
- Date: Tue, 1 Dec 2020 17:08:49 +0300
- Cc: Kees Cook <keescook@xxxxxxxxxxxx>, alsa-devel@xxxxxxxxxxxxxxxx, linux-atm-general@xxxxxxxxxxxxxxxxxxxxx, reiserfs-devel@xxxxxxxxxxxxxxx, linux-iio@xxxxxxxxxxxxxxx, linux-wireless <linux-wireless@xxxxxxxxxxxxxxx>, linux-fbdev@xxxxxxxxxxxxxxx, dri-devel <dri-devel@xxxxxxxxxxxxxxxxxxxxx>, LKML <linux-kernel@xxxxxxxxxxxxxxx>, Nathan Chancellor <natechancellor@xxxxxxxxx>, linux-ide@xxxxxxxxxxxxxxx, dm-devel@xxxxxxxxxx, keyrings@xxxxxxxxxxxxxxx, linux-mtd@xxxxxxxxxxxxxxxxxxx, GR-everest-linux-l2@xxxxxxxxxxx, wcn36xx@xxxxxxxxxxxxxxxxxxx, samba-technical@xxxxxxxxxxxxxxx, linux-i3c@xxxxxxxxxxxxxxxxxxx, linux1394-devel@xxxxxxxxxxxxxxxxxxxxx, linux-afs@xxxxxxxxxxxxxxxxxxx, usb-storage@xxxxxxxxxxxxxxxxxxxxxxxx, drbd-dev@xxxxxxxxxxxxxxx, devel@xxxxxxxxxxxxxxxxxxxx, linux-cifs@xxxxxxxxxxxxxxx, rds-devel@xxxxxxxxxxxxxx, linux-scsi@xxxxxxxxxxxxxxx, linux-rdma@xxxxxxxxxxxxxxx, oss-drivers@xxxxxxxxxxxxx, bridge@xxxxxxxxxxxxxxxxxxxxxxxxxx, linux-security-module@xxxxxxxxxxxxxxx, amd-gfx list <amd-gfx@xxxxxxxxxxxxxxxxxxxxx>, linux-stm32@xxxxxxxxxxxxxxxxxxxxxxxxxxxx, cluster-devel@xxxxxxxxxx, linux-acpi@xxxxxxxxxxxxxxx, coreteam@xxxxxxxxxxxxx, intel-wired-lan@xxxxxxxxxxxxxxxx, linux-input@xxxxxxxxxxxxxxx, Miguel Ojeda <ojeda@xxxxxxxxxx>, Jakub Kicinski <kuba@xxxxxxxxxx>, linux-ext4@xxxxxxxxxxxxxxx, linux-media@xxxxxxxxxxxxxxx, linux-watchdog@xxxxxxxxxxxxxxx, selinux@xxxxxxxxxxxxxxx, linux-arm-msm <linux-arm-msm@xxxxxxxxxxxxxxx>, intel-gfx@xxxxxxxxxxxxxxxxxxxxx, linux-geode@xxxxxxxxxxxxxxxxxxx, linux-can@xxxxxxxxxxxxxxx, linux-block@xxxxxxxxxxxxxxx, linux-gpio@xxxxxxxxxxxxxxx, op-tee@xxxxxxxxxxxxxxxxxxxxxxxxx, linux-mediatek@xxxxxxxxxxxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxxx, nouveau@xxxxxxxxxxxxxxxxxxxxx, linux-hams@xxxxxxxxxxxxxxx, ceph-devel@xxxxxxxxxxxxxxx, virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx, Linux ARM <linux-arm-kernel@xxxxxxxxxxxxxxxxxxx>, linux-hwmon@xxxxxxxxxxxxxxx, "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@xxxxxxxxxx>, linux-nfs@xxxxxxxxxxxxxxx, GR-Linux-NIC-Dev@xxxxxxxxxxx, tipc-discussion@xxxxxxxxxxxxxxxxxxxxx, Linux Memory Management List <linux-mm@xxxxxxxxx>, Network Development <netdev@xxxxxxxxxxxxxxx>, linux-decnet-user@xxxxxxxxxxxxxxxxxxxxx, linux-mmc@xxxxxxxxxxxxxxx, "Gustavo A. R. Silva" <gustavoars@xxxxxxxxxx>, Linux-Renesas <linux-renesas-soc@xxxxxxxxxxxxxxx>, linux-sctp@xxxxxxxxxxxxxxx, linux-usb@xxxxxxxxxxxxxxx, netfilter-devel@xxxxxxxxxxxxxxx, "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" <linux-crypto@xxxxxxxxxxxxxxx>, patches@xxxxxxxxxxxxxxxxxxxxx, Joe Perches <joe@xxxxxxxxxxx>, linux-integrity@xxxxxxxxxxxxxxx, target-devel@xxxxxxxxxxxxxxx, linux-hardening@xxxxxxxxxxxxxxx
- Delivery-date: Tue, 01 Dec 2020 14:10:04 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
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@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxx/
>
> 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
|