From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B1629C2D0E4 for ; Tue, 24 Nov 2020 00:58:46 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0D46720715 for ; Tue, 24 Nov 2020 00:58:45 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0D46720715 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=telegraphics.com.au Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 240356B005D; Mon, 23 Nov 2020 19:58:45 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1F04E6B006E; Mon, 23 Nov 2020 19:58:45 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 107256B0070; Mon, 23 Nov 2020 19:58:45 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0125.hostedemail.com [216.40.44.125]) by kanga.kvack.org (Postfix) with ESMTP id D820D6B005D for ; Mon, 23 Nov 2020 19:58:44 -0500 (EST) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 8965E181AC9B6 for ; Tue, 24 Nov 2020 00:58:44 +0000 (UTC) X-FDA: 77517501768.26.cable84_5d0daf127369 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin26.hostedemail.com (Postfix) with ESMTP id 706131804B667 for ; Tue, 24 Nov 2020 00:58:44 +0000 (UTC) X-HE-Tag: cable84_5d0daf127369 X-Filterd-Recvd-Size: 7677 Received: from kvm5.telegraphics.com.au (kvm5.telegraphics.com.au [98.124.60.144]) by imf19.hostedemail.com (Postfix) with ESMTP for ; Tue, 24 Nov 2020 00:58:43 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by kvm5.telegraphics.com.au (Postfix) with ESMTP id 0EF842A8E0; Mon, 23 Nov 2020 19:58:39 -0500 (EST) Date: Tue, 24 Nov 2020 11:58:37 +1100 (AEDT) From: Finn Thain To: Miguel Ojeda cc: James Bottomley , Kees Cook , Jakub Kicinski , "Gustavo A. R. Silva" , linux-kernel , alsa-devel@alsa-project.org, amd-gfx@lists.freedesktop.org, bridge@lists.linux-foundation.org, ceph-devel@vger.kernel.org, cluster-devel@redhat.com, coreteam@netfilter.org, devel@driverdev.osuosl.org, dm-devel@redhat.com, drbd-dev@lists.linbit.com, dri-devel@lists.freedesktop.org, GR-everest-linux-l2@marvell.com, GR-Linux-NIC-Dev@marvell.com, intel-gfx@lists.freedesktop.org, intel-wired-lan@lists.osuosl.org, keyrings@vger.kernel.org, linux1394-devel@lists.sourceforge.net, linux-acpi@vger.kernel.org, linux-afs@lists.infradead.org, Linux ARM , linux-arm-msm@vger.kernel.org, linux-atm-general@lists.sourceforge.net, linux-block@vger.kernel.org, linux-can@vger.kernel.org, linux-cifs@vger.kernel.org, Linux Crypto Mailing List , linux-decnet-user@lists.sourceforge.net, Ext4 Developers List , linux-fbdev@vger.kernel.org, linux-geode@lists.infradead.org, linux-gpio@vger.kernel.org, linux-hams@vger.kernel.org, linux-hwmon@vger.kernel.org, linux-i3c@lists.infradead.org, linux-ide@vger.kernel.org, linux-iio@vger.kernel.org, linux-input , linux-integrity@vger.kernel.org, linux-mediatek@lists.infradead.org, Linux Media Mailing List , linux-mmc@vger.kernel.org, Linux-MM , linux-mtd@lists.infradead.org, linux-nfs@vger.kernel.org, linux-rdma@vger.kernel.org, linux-renesas-soc@vger.kernel.org, linux-scsi@vger.kernel.org, linux-sctp@vger.kernel.org, linux-security-module@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, linux-usb@vger.kernel.org, linux-watchdog@vger.kernel.org, linux-wireless , Network Development , netfilter-devel@vger.kernel.org, nouveau@lists.freedesktop.org, op-tee@lists.trustedfirmware.org, oss-drivers@netronome.com, patches@opensource.cirrus.com, rds-devel@oss.oracle.com, reiserfs-devel@vger.kernel.org, samba-technical@lists.samba.org, selinux@vger.kernel.org, target-devel@vger.kernel.org, tipc-discussion@lists.sourceforge.net, usb-storage@lists.one-eyed-alien.net, virtualization@lists.linux-foundation.org, wcn36xx@lists.infradead.org, "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , xen-devel@lists.xenproject.org, linux-hardening@vger.kernel.org, Nick Desaulniers , Nathan Chancellor , Miguel Ojeda , Joe Perches Subject: Re: [PATCH 000/141] Fix fall-through warnings for Clang In-Reply-To: Message-ID: References: <20201120105344.4345c14e@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <202011201129.B13FDB3C@keescook> <20201120115142.292999b2@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <202011220816.8B6591A@keescook> <9b57fd4914b46f38d54087d75e072d6e947cb56d.camel@HansenPartnership.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, 23 Nov 2020, Miguel Ojeda wrote: > On Mon, 23 Nov 2020, Finn Thain wrote: > > > On Sun, 22 Nov 2020, Miguel Ojeda wrote: > > > > > > > > It isn't that much effort, isn't it? Plus we need to take into > > > account the future mistakes that it might prevent, too. > > > > We should also take into account optimisim about future improvements > > in tooling. > > > Not sure what you mean here. There is no reliable way to guess what the > intention was with a missing fallthrough, even if you parsed whitespace > and indentation. > What I meant was that you've used pessimism as if it was fact. For example, "There is no way to guess what the effect would be if the compiler trained programmers to add a knee-jerk 'break' statement to avoid a warning". Moreover, what I meant was that preventing programmer mistakes is a problem to be solved by development tools. The idea that retro-fitting new language constructs onto mature code is somehow necessary to "prevent future mistakes" is entirely questionable. > > > So even if there were zero problems found so far, it is still a > > > positive change. > > > > > > > It is if you want to spin it that way. > > > How is that a "spin"? It is a fact that we won't get *implicit* > fallthrough mistakes anymore (in particular if we make it a hard error). > Perhaps "handwaving" is a better term? > > > I would agree if these changes were high risk, though; but they are > > > almost trivial. > > > > > > > This is trivial: > > > > case 1: > > this(); > > + fallthrough; > > case 2: > > that(); > > > > But what we inevitably get is changes like this: > > > > case 3: > > this(); > > + break; > > case 4: > > hmmm(); > > > > Why? Mainly to silence the compiler. Also because the patch author > > argued successfully that they had found a theoretical bug, often in > > mature code. > > > If someone changes control flow, that is on them. Every kernel developer > knows what `break` does. > Sure. And if you put -Wimplicit-fallthrough into the Makefile and if that leads to well-intentioned patches that cause regressions, it is partly on you. Have you ever considered the overall cost of the countless -Wpresume-incompetence flags? Perhaps you pay the power bill for a build farm that produces logs that no-one reads? Perhaps you've run git bisect, knowing that the compiler messages are not interesting? Or compiled software in using a language that generates impenetrable messages? If so, here's a tip: # grep CFLAGS /etc/portage/make.conf CFLAGS="... -Wno-all -Wno-extra ..." CXXFLAGS="${CFLAGS}" Now allow me some pessimism: the hardware upgrades, gigawatt hours and wait time attributable to obligatory static analyses are a net loss. > > But is anyone keeping score of the regressions? If unreported bugs > > count, what about unreported regressions? > > > Introducing `fallthrough` does not change semantics. If you are really > keen, you can always compare the objects because the generated code > shouldn't change. > No, it's not for me to prove that such patches don't affect code generation. That's for the patch author and (unfortunately) for reviewers. > Cheers, > Miguel >