Thread (72 messages) 72 messages, 22 authors, 2020-12-08

Re: [PATCH 000/141] Fix fall-through warnings for Clang

From: James Bottomley <James.Bottomley@HansenPartnership.com>
Date: 2020-11-22 18:22:32
Also in: alsa-devel, amd-gfx, bridge, ceph-devel, dm-devel, dri-devel, intel-gfx, intel-wired-lan, keyrings, linux-acpi, linux-arm-msm, linux-block, linux-can, linux-cifs, linux-crypto, linux-ext4, linux-fbdev, linux-gpio, linux-hardening, linux-hwmon, linux-i3c, linux-ide, linux-iio, linux-integrity, linux-media, linux-mediatek, linux-mm, linux-mmc, linux-nfs, linux-rdma, linux-renesas-soc, linux-scsi, linux-sctp, linux-security-module, linux-usb, linux-watchdog, linux-wireless, lkml, netdev, netfilter-devel, op-tee, selinux, target-devel, xen-devel

On Sun, 2020-11-22 at 08:17 -0800, Kees Cook wrote:
On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
quoted
On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
quoted
On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
quoted
On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:  
quoted
This series aims to fix almost all remaining fall-through
warnings in order to enable -Wimplicit-fallthrough for Clang.

In preparation to enable -Wimplicit-fallthrough for Clang,
explicitly add multiple break/goto/return/fallthrough
statements instead of just letting the code fall through to
the next case.

Notice that in order to enable -Wimplicit-fallthrough for
Clang, this change[1] is meant to be reverted at some point.
So, this patch helps to move in that direction.

Something important to mention is that there is currently a
discrepancy between GCC and Clang when dealing with switch
fall-through to empty case statements or to cases that only
contain a break/continue/return statement[2][3][4].  
Are we sure we want to make this change? Was it discussed
before?

Are there any bugs Clangs puritanical definition of fallthrough
helped find?

IMVHO compiler warnings are supposed to warn about issues that
could be bugs. Falling through to default: break; can hardly be
a bug?!  
It's certainly a place where the intent is not always clear. I
think this makes all the cases unambiguous, and doesn't impact
the machine code, since the compiler will happily optimize away
any behavioral redundancy.
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/ (local)

Well, it's a problem in an error leg, sure, but it's not a really
compelling reason for a 141 patch series, is it?  All that fixing this
error will do is get the driver to print "oh dear there's a problem"
under four more conditions than it previously did.

We've been at this for three years now with nearly a thousand patches,
firstly marking all the fall throughs with /* fall through */ and later
changing it to fallthrough.  At some point we do have to ask if the
effort is commensurate with the protection afforded.  Please tell me
our reward for all this effort isn't a single missing error print.

James

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help