Target-devel archive on lore.kernel.org
 help / color / Atom feed
From: Finn Thain <fthain@telegraphics.com.au>
To: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Cc: James Bottomley <James.Bottomley@hansenpartnership.com>,
	Kees Cook <keescook@chromium.org>,
	Jakub Kicinski <kuba@kernel.org>,
	"Gustavo A. R. Silva" <gustavoars@kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	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-kernel@lists.infradead.org>,
	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-crypto@vger.kernel.org>,
	linux-decnet-user@lists.sourceforge.net,
	Ext4 Developers List <linux-ext4@vger.kernel.org>,
	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-input@vger.kernel.org>,
	linux-integrity@vger.kernel.org,
	linux-mediatek@lists.infradead.org,
	Linux Media Mailing List <linux-media@vger.kernel.org>,
	linux-mmc@vger.kernel.org, Linux-MM <linux-mm@kvack.org>,
	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 <linux-wireless@vger.kernel.org>,
	Network Development <netdev@vger.kernel.org>,
	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)"
	<x86@kernel.org>,
	xen-devel@lists.xenproject.org, linux-hardening@vger.kernel.org,
	Nick Desaulniers <ndesaulniers@google.com>,
	Nathan Chancellor <natechancellor@gmail.com>,
	Miguel Ojeda <ojeda@kernel.org>, Joe Perches <joe@perches.com>
Subject: Re: [PATCH 000/141] Fix fall-through warnings for Clang
Date: Tue, 24 Nov 2020 11:58:37 +1100 (AEDT)
Message-ID: <alpine.LNX.2.23.453.2011241036520.7@nippy.intranet> (raw)
In-Reply-To: <CANiq72=z+tmuey9wj3Kk7wX5s0hTHpsQdLhAqcOVNrHon6xn5Q@mail.gmail.com>


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
> 

  reply index

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-20 18:21 Gustavo A. R. Silva
2020-11-20 18:28 ` Joe Perches
2020-11-20 19:02   ` Gustavo A. R. Silva
2020-11-20 18:32 ` [PATCH 054/141] target: " Gustavo A. R. Silva
2020-11-20 18:53 ` [PATCH 000/141] " Jakub Kicinski
2020-11-20 19:04   ` Gustavo A. R. Silva
2020-11-20 19:30   ` Kees Cook
2020-11-20 19:51     ` Jakub Kicinski
2020-11-20 20:48       ` Kees Cook
2020-11-22 16:17       ` Kees Cook
2020-11-22 18:21         ` James Bottomley
2020-11-22 18:25           ` Joe Perches
2020-11-22 19:12             ` James Bottomley
2020-11-22 19:22               ` Joe Perches
2020-11-22 19:53                 ` James Bottomley
2020-11-23 13:03                   ` [Intel-wired-lan] " Gustavo A. R. Silva
2020-11-23 16:31                     ` James Bottomley
2020-11-24 21:32                       ` Kees Cook
2020-11-24 22:24                         ` Finn Thain
2020-11-24 23:15                           ` Miguel Ojeda
2020-11-24 23:53                             ` Finn Thain
2020-11-25  1:05                               ` Miguel Ojeda
2020-11-25  7:05                         ` James Bottomley
2020-11-25 12:24                           ` Nick Desaulniers
2020-11-25 21:33                             ` Finn Thain
2020-11-25 22:09                               ` Nick Desaulniers
2020-11-25 23:21                                 ` Finn Thain
2020-11-26  0:30                                 ` Finn Thain
2020-11-25 21:10                           ` Kees Cook
2020-11-22 20:35           ` Miguel Ojeda
2020-11-22 22:36             ` James Bottomley
2020-11-23 14:19               ` Miguel Ojeda
2020-11-23 15:58                 ` James Bottomley
2020-11-23 16:24                   ` Rafael J. Wysocki
2020-11-23 16:32                   ` Joe Perches
2020-11-23 18:56                   ` Miguel Ojeda
2020-11-23 20:37                     ` James Bottomley
2020-11-25  0:32                       ` Miguel Ojeda
2020-11-25 22:44                         ` Edward Cree
2020-11-26 14:53                           ` Miguel Ojeda
2020-11-26 15:28                             ` Geert Uytterhoeven
2020-11-26 16:18                               ` Karol Herbst
2020-11-26 17:05                               ` Miguel Ojeda
2020-11-25 10:38                       ` Andy Shevchenko
2020-11-25  9:01                   ` Sean Young
2020-11-22 22:54             ` Finn Thain
2020-11-22 23:04               ` James Bottomley
2020-11-23 14:05               ` Miguel Ojeda
2020-11-24  0:58                 ` Finn Thain [this message]
2020-11-24  1:05                   ` Joe Perches
2020-11-24  2:48                     ` Finn Thain
2020-11-24 23:46                   ` Miguel Ojeda
2020-11-22 22:10           ` Sam Ravnborg
2020-11-24  1:32         ` Nick Desaulniers
2020-11-24 21:25           ` Kees Cook
2020-11-25 23:02             ` Edward Cree
2020-12-01 14:08           ` Dan Carpenter
2020-12-01 14:04         ` Dan Carpenter
2020-11-20 22:21 ` Miguel Ojeda
2020-11-23 20:03 ` Jason Gunthorpe
2020-11-24 14:47   ` Gustavo A. R. Silva
     [not found] ` <160616392671.21180.16517492185091399884.b4-ty@kernel.org>
2020-11-24 14:47   ` Gustavo A. R. Silva
2020-12-01  5:52 ` Martin K. Petersen
2020-12-01  8:20   ` Gustavo A. R. Silva
2020-12-08  4:52 ` (subset) " Martin K. Petersen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LNX.2.23.453.2011241036520.7@nippy.intranet \
    --to=fthain@telegraphics.com.au \
    --cc=GR-Linux-NIC-Dev@marvell.com \
    --cc=GR-everest-linux-l2@marvell.com \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=bridge@lists.linux-foundation.org \
    --cc=ceph-devel@vger.kernel.org \
    --cc=cluster-devel@redhat.com \
    --cc=coreteam@netfilter.org \
    --cc=devel@driverdev.osuosl.org \
    --cc=dm-devel@redhat.com \
    --cc=drbd-dev@lists.linbit.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gustavoars@kernel.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=joe@perches.com \
    --cc=keescook@chromium.org \
    --cc=keyrings@vger.kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-afs@lists.infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-atm-general@lists.sourceforge.net \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-can@vger.kernel.org \
    --cc=linux-cifs@vger.kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-decnet-user@lists.sourceforge.net \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-geode@lists.infradead.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-hams@vger.kernel.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=linux-i3c@lists.infradead.org \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=linux-sctp@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=linux-stm32@st-md-mailman.stormreply.com \
    --cc=linux-usb@vger.kernel.org \
    --cc=linux-watchdog@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linux1394-devel@lists.sourceforge.net \
    --cc=miguel.ojeda.sandonis@gmail.com \
    --cc=natechancellor@gmail.com \
    --cc=ndesaulniers@google.com \
    --cc=netdev@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=nouveau@lists.freedesktop.org \
    --cc=ojeda@kernel.org \
    --cc=op-tee@lists.trustedfirmware.org \
    --cc=oss-drivers@netronome.com \
    --cc=patches@opensource.cirrus.com \
    --cc=rds-devel@oss.oracle.com \
    --cc=reiserfs-devel@vger.kernel.org \
    --cc=samba-technical@lists.samba.org \
    --cc=selinux@vger.kernel.org \
    --cc=target-devel@vger.kernel.org \
    --cc=tipc-discussion@lists.sourceforge.net \
    --cc=usb-storage@lists.one-eyed-alien.net \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=wcn36xx@lists.infradead.org \
    --cc=x86@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Target-devel archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/target-devel/0 target-devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 target-devel target-devel/ https://lore.kernel.org/target-devel \
		target-devel@vger.kernel.org
	public-inbox-index target-devel

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.target-devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git