All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joe Perches <joe@perches.com>
To: Nick Desaulniers <ndesaulniers@google.com>, Tom Rix <trix@redhat.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	linux-edac@vger.kernel.org, linux-acpi@vger.kernel.org,
	linux-pm@vger.kernel.org, xen-devel@lists.xenproject.org,
	linux-block@vger.kernel.org,
	openipmi-developer@lists.sourceforge.net,
	"open list:HARDWARE RANDOM NUMBER GENERATOR CORE 
	<linux-crypto@vger.kernel.org>,
	Linux ARM" <linux-arm-kernel@lists.infradead.org>,
	linux-power@fi.rohmeurope.com, linux-gpio@vger.kernel.org,
	amd-gfx list <amd-gfx@lists.freedesktop.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	nouveau@lists.freedesktop.org,
	virtualization@lists.linux-foundation.org,
	spice-devel@lists.freedesktop.org, linux-iio@vger.kernel.org,
	linux-amlogic@lists.infradead.org,
	industrypack-devel@lists.sourceforge.net,
	linux-media@vger.kernel.org, MPT-FusionLinux.pdl@broadcom.com,
	linux-scsi@vger.kernel.org, linux-mtd@lists.infradead.org,
	linux-can@vger.kernel.org,
	Network Development <netdev@vger.kernel.org>,
	intel-wired-lan@lists.osuosl.org, ath10k@lists.infradead.org,
	linux-wireless <lin ux-wireless@vger.kernel.org>,
	linux-stm32@st-md-mailman.stormreply.com, linux-nfc@lists.01.org,
	linux-nvdimm <linux-nvdimm@lists.01.org>,
	linux-pci@vger.kernel.org, linux-samsung-soc@vger.kernel.org,
	platform-driver-x86@vger.kernel.org,
	patches@opensource.cirrus.com, storagedev@microchip.com,
	devel@driverdev.osuosl.org, linux-serial@vger.kernel.org,
	linux-usb@vger.kernel.org, usb-storage@lists.one-eyed-alien.net,
	linux-watchdog@vger.kernel.org, ocfs2-devel@oss.oracle.com,
	bpf <bpf@vger.kernel.org>,
	linux-integrity@vger.kernel.org,
	linux-security-module@vger.kernel.org, keyrings@vger.kernel.org,
	alsa-devel@alsa-project.org,
	clang-built-linux <clang-built-linux@googlegroups.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	George Burgess <gbiv@google.com>
Subject: Re: [RFC] treewide: cleanup unreachable breaks
Date: Tue, 20 Oct 2020 11:42:42 -0700	[thread overview]
Message-ID: <3bc5c2e3b3edc22a4d167ec807ecdaaf8dcda76d.camel@perches.com> (raw)
In-Reply-To: <CAKwvOdkR_Ttfo7_JKUiZFVqr=Uh=4b05KCPCSuzwk=zaWtA2_Q@mail.gmail.com>

On Mon, 2020-10-19 at 12:42 -0700, Nick Desaulniers wrote:
> On Sat, Oct 17, 2020 at 10:43 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> > On Sat, Oct 17, 2020 at 09:09:28AM -0700, trix@redhat.com wrote:
> > > From: Tom Rix <trix@redhat.com>
> > > 
> > > This is a upcoming change to clean up a new warning treewide.
> > > I am wondering if the change could be one mega patch (see below) or
> > > normal patch per file about 100 patches or somewhere half way by collecting
> > > early acks.
> > 
> > Please break it up into one-patch-per-subsystem, like normal, and get it
> > merged that way.
> > 
> > Sending us a patch, without even a diffstat to review, isn't going to
> > get you very far...
> 
> Tom,
> If you're able to automate this cleanup, I suggest checking in a
> script that can be run on a directory.  Then for each subsystem you
> can say in your commit "I ran scripts/fix_whatever.py on this subdir."
>  Then others can help you drive the tree wide cleanup.  Then we can
> enable -Wunreachable-code-break either by default, or W=2 right now
> might be a good idea.
> 
> Ah, George (gbiv@, cc'ed), did an analysis recently of
> `-Wunreachable-code-loop-increment`, `-Wunreachable-code-break`, and
> `-Wunreachable-code-return` for Android userspace.  From the review:
> ```
> Spoilers: of these, it seems useful to turn on
> -Wunreachable-code-loop-increment and -Wunreachable-code-return by
> default for Android
> ...
> While these conventions about always having break arguably became
> obsolete when we enabled -Wfallthrough, my sample turned up zero
> potential bugs caught by this warning, and we'd need to put a lot of
> effort into getting a clean tree. So this warning doesn't seem to be
> worth it.
> ```
> Looks like there's an order of magnitude of `-Wunreachable-code-break`
> than the other two.
> 
> We probably should add all 3 to W=2 builds (wrapped in cc-option).
> I've filed https://github.com/ClangBuiltLinux/linux/issues/1180 to
> follow up on.

I suggest using W=1 as people that are doing cleanups
generally use that and not W=123 or any other style.

Every other use of W= is still quite noisy and these
code warnings are relatively trivially to fix up.

_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-leave@lists.01.org

WARNING: multiple messages have this Message-ID (diff)
From: Joe Perches <joe@perches.com>
To: Nick Desaulniers <ndesaulniers@google.com>, Tom Rix <trix@redhat.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	linux-edac@vger.kernel.org, linux-acpi@vger.kernel.org,
	linux-pm@vger.kernel.org, xen-devel@lists.xenproject.org,
	linux-block@vger.kernel.org,
	openipmi-developer@lists.sourceforge.net,
	"open list:HARDWARE RANDOM NUMBER GENERATOR CORE" 
	<linux-crypto@vger.kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	linux-power@fi.rohmeurope.com, linux-gpio@vger.kernel.org,
	amd-gfx list <amd-gfx@lists.freedesktop.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	nouveau@lists.freedesktop.org,
	virtualization@lists.linux-foundation.org,
	spice-devel@lists.freedesktop.org, linux-iio@vger.kernel.org,
	linux-amlogic@lists.infradead.org,
	industrypack-devel@lists.sourceforge.net,
	linux-media@vger.kernel.org, MPT-FusionLinux.pdl@broadcom.com,
	linux-scsi@vger.kernel.org, linux-mtd@lists.infradead.org,
	linux-can@vger.kernel.org,
	Network Development <netdev@vger.kernel.org>,
	intel-wired-lan@lists.osuosl.org, ath10k@lists.infradead.org,
	linux-wireless <linux-wireless@vger.kernel.org>,
	linux-stm32@st-md-mailman.stormreply.com, linux-nfc@lists.01.org,
	linux-nvdimm <linux-nvdimm@lists.01.org>,
	linux-pci@vger.kernel.org, linux-samsung-soc@vger.kernel.org,
	platform-driver-x86@vger.kernel.org,
	patches@opensource.cirrus.com, storagedev@microchip.com,
	devel@driverdev.osuosl.org, linux-serial@vger.kernel.org,
	linux-usb@vger.kernel.org, usb-storage@lists.one-eyed-alien.net,
	linux-watchdog@vger.kernel.org, ocfs2-devel@oss.oracle.com,
	bpf <bpf@vger.kernel.org>,
	linux-integrity@vger.kernel.org,
	linux-security-module@vger.kernel.org, keyrings@vger.kernel.org,
	alsa-devel@alsa-project.org,
	clang-built-linux <clang-built-linux@googlegroups.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	George Burgess <gbiv@google.com>
Subject: Re: [RFC] treewide: cleanup unreachable breaks
Date: Tue, 20 Oct 2020 11:42:42 -0700	[thread overview]
Message-ID: <3bc5c2e3b3edc22a4d167ec807ecdaaf8dcda76d.camel@perches.com> (raw)
In-Reply-To: <CAKwvOdkR_Ttfo7_JKUiZFVqr=Uh=4b05KCPCSuzwk=zaWtA2_Q@mail.gmail.com>

On Mon, 2020-10-19 at 12:42 -0700, Nick Desaulniers wrote:
> On Sat, Oct 17, 2020 at 10:43 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> > On Sat, Oct 17, 2020 at 09:09:28AM -0700, trix@redhat.com wrote:
> > > From: Tom Rix <trix@redhat.com>
> > > 
> > > This is a upcoming change to clean up a new warning treewide.
> > > I am wondering if the change could be one mega patch (see below) or
> > > normal patch per file about 100 patches or somewhere half way by collecting
> > > early acks.
> > 
> > Please break it up into one-patch-per-subsystem, like normal, and get it
> > merged that way.
> > 
> > Sending us a patch, without even a diffstat to review, isn't going to
> > get you very far...
> 
> Tom,
> If you're able to automate this cleanup, I suggest checking in a
> script that can be run on a directory.  Then for each subsystem you
> can say in your commit "I ran scripts/fix_whatever.py on this subdir."
>  Then others can help you drive the tree wide cleanup.  Then we can
> enable -Wunreachable-code-break either by default, or W=2 right now
> might be a good idea.
> 
> Ah, George (gbiv@, cc'ed), did an analysis recently of
> `-Wunreachable-code-loop-increment`, `-Wunreachable-code-break`, and
> `-Wunreachable-code-return` for Android userspace.  From the review:
> ```
> Spoilers: of these, it seems useful to turn on
> -Wunreachable-code-loop-increment and -Wunreachable-code-return by
> default for Android
> ...
> While these conventions about always having break arguably became
> obsolete when we enabled -Wfallthrough, my sample turned up zero
> potential bugs caught by this warning, and we'd need to put a lot of
> effort into getting a clean tree. So this warning doesn't seem to be
> worth it.
> ```
> Looks like there's an order of magnitude of `-Wunreachable-code-break`
> than the other two.
> 
> We probably should add all 3 to W=2 builds (wrapped in cc-option).
> I've filed https://github.com/ClangBuiltLinux/linux/issues/1180 to
> follow up on.

I suggest using W=1 as people that are doing cleanups
generally use that and not W=123 or any other style.

Every other use of W= is still quite noisy and these
code warnings are relatively trivially to fix up.



WARNING: multiple messages have this Message-ID (diff)
From: Joe Perches <joe@perches.com>
To: Nick Desaulniers <ndesaulniers@google.com>, Tom Rix <trix@redhat.com>
Cc: alsa-devel@alsa-project.org,
	clang-built-linux <clang-built-linux@googlegroups.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	linux-iio@vger.kernel.org, nouveau@lists.freedesktop.org,
	storagedev@microchip.com,
	dri-devel <dri-devel@lists.freedesktop.org>,
	virtualization@lists.linux-foundation.org,
	keyrings@vger.kernel.org, linux-mtd@lists.infradead.org,
	ath10k@lists.infradead.org,
	linux-stm32@st-md-mailman.stormreply.com,
	usb-storage@lists.one-eyed-alien.net,
	linux-watchdog@vger.kernel.org, devel@driverdev.osuosl.org,
	linux-samsung-soc@vger.kernel.org, linux-scsi@vger.kernel.org,
	linux-nvdimm <linux-nvdimm@lists.01.org>,
	amd-gfx list <amd-gfx@lists.freedesktop.org>,
	linux-acpi@vger.kernel.org, intel-wired-lan@lists.osuosl.org,
	industrypack-devel@lists.sourceforge.net,
	linux-pci@vger.kernel.org, spice-devel@lists.freedesktop.org,
	MPT-FusionLinux.pdl@broadcom.com, linux-media@vger.kernel.org,
	linux-serial@vger.kernel.org, linux-nfc@lists.01.org,
	linux-pm@vger.kernel.org, linux-can@vger.kernel.org,
	linux-block@vger.kernel.org, linux-gpio@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	linux-amlogic@lists.infradead.org,
	openipmi-developer@lists.sourceforge.net,
	platform-driver-x86@vger.kernel.org,
	linux-integrity@vger.kernel.org,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	linux-edac@vger.kernel.org, George Burgess <gbiv@google.com>,
	Network Development <netdev@vger.kernel.org>,
	linux-usb@vger.kernel.org,
	linux-wireless <linux-wireless@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-security-module@vger.kernel.org,
	"open list:HARDWARE RANDOM NUMBER GENERATOR CORE"
	<linux-crypto@vger.kernel.org>,
	patches@opensource.cirrus.com, bpf <bpf@vger.kernel.org>,
	ocfs2-devel@oss.oracle.com, linux-power@fi.rohmeurope.com
Subject: [Ocfs2-devel] [RFC] treewide: cleanup unreachable breaks
Date: Tue, 20 Oct 2020 11:42:42 -0700	[thread overview]
Message-ID: <3bc5c2e3b3edc22a4d167ec807ecdaaf8dcda76d.camel@perches.com> (raw)
In-Reply-To: <CAKwvOdkR_Ttfo7_JKUiZFVqr=Uh=4b05KCPCSuzwk=zaWtA2_Q@mail.gmail.com>

On Mon, 2020-10-19 at 12:42 -0700, Nick Desaulniers wrote:
> On Sat, Oct 17, 2020 at 10:43 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> > On Sat, Oct 17, 2020 at 09:09:28AM -0700, trix at redhat.com wrote:
> > > From: Tom Rix <trix@redhat.com>
> > > 
> > > This is a upcoming change to clean up a new warning treewide.
> > > I am wondering if the change could be one mega patch (see below) or
> > > normal patch per file about 100 patches or somewhere half way by collecting
> > > early acks.
> > 
> > Please break it up into one-patch-per-subsystem, like normal, and get it
> > merged that way.
> > 
> > Sending us a patch, without even a diffstat to review, isn't going to
> > get you very far...
> 
> Tom,
> If you're able to automate this cleanup, I suggest checking in a
> script that can be run on a directory.  Then for each subsystem you
> can say in your commit "I ran scripts/fix_whatever.py on this subdir."
>  Then others can help you drive the tree wide cleanup.  Then we can
> enable -Wunreachable-code-break either by default, or W=2 right now
> might be a good idea.
> 
> Ah, George (gbiv@, cc'ed), did an analysis recently of
> `-Wunreachable-code-loop-increment`, `-Wunreachable-code-break`, and
> `-Wunreachable-code-return` for Android userspace.  From the review:
> ```
> Spoilers: of these, it seems useful to turn on
> -Wunreachable-code-loop-increment and -Wunreachable-code-return by
> default for Android
> ...
> While these conventions about always having break arguably became
> obsolete when we enabled -Wfallthrough, my sample turned up zero
> potential bugs caught by this warning, and we'd need to put a lot of
> effort into getting a clean tree. So this warning doesn't seem to be
> worth it.
> ```
> Looks like there's an order of magnitude of `-Wunreachable-code-break`
> than the other two.
> 
> We probably should add all 3 to W=2 builds (wrapped in cc-option).
> I've filed https://github.com/ClangBuiltLinux/linux/issues/1180 to
> follow up on.

I suggest using W=1 as people that are doing cleanups
generally use that and not W=123 or any other style.

Every other use of W= is still quite noisy and these
code warnings are relatively trivially to fix up.

WARNING: multiple messages have this Message-ID (diff)
From: Joe Perches <joe@perches.com>
To: Nick Desaulniers <ndesaulniers@google.com>, Tom Rix <trix@redhat.com>
Cc: alsa-devel@alsa-project.org,
	clang-built-linux <clang-built-linux@googlegroups.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	linux-iio@vger.kernel.org, nouveau@lists.freedesktop.org,
	storagedev@microchip.com,
	dri-devel <dri-devel@lists.freedesktop.org>,
	virtualization@lists.linux-foundation.org,
	keyrings@vger.kernel.org, linux-mtd@lists.infradead.org,
	ath10k@lists.infradead.org,
	linux-stm32@st-md-mailman.stormreply.com,
	usb-storage@lists.one-eyed-alien.net,
	linux-watchdog@vger.kernel.org, devel@driverdev.osuosl.org,
	linux-samsung-soc@vger.kernel.org, linux-scsi@vger.kernel.org,
	linux-nvdimm <linux-nvdimm@lists.01.org>,
	amd-gfx list <amd-gfx@lists.freedesktop.org>,
	linux-acpi@vger.kernel.org, intel-wired-lan@lists.osuosl.org,
	industrypack-devel@lists.sourceforge.net,
	linux-pci@vger.kernel.org, spice-devel@lists.freedesktop.org,
	MPT-FusionLinux.pdl@broadcom.com, linux-media@vger.kernel.org,
	linux-serial@vger.kernel.org, linux-nfc@lists.01.org,
	linux-pm@vger.kernel.org, linux-can@vger.kernel.org,
	linux-block@vger.kernel.org, linux-gpio@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	linux-amlogic@lists.infradead.org,
	openipmi-developer@lists.sourceforge.net,
	platform-driver-x86@vger.kernel.org,
	linux-integrity@vger.kernel.org,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	linux-edac@vger.kernel.org, George Burgess <gbiv@google.com>,
	Network Development <netdev@vger.kernel.org>,
	linux-usb@vger.kernel.org,
	linux-wireless <linux-wireless@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-security-module@vger.kernel.org,
	"open list:HARDWARE RANDOM NUMBER GENERATOR CORE"
	<linux-crypto@vger.kernel.org>,
	patches@opensource.cirrus.com, bpf <bpf@vger.kernel.org>,
	ocfs2-devel@oss.oracle.com, linux-power@fi.rohmeurope.com
Subject: Re: [RFC] treewide: cleanup unreachable breaks
Date: Tue, 20 Oct 2020 11:42:42 -0700	[thread overview]
Message-ID: <3bc5c2e3b3edc22a4d167ec807ecdaaf8dcda76d.camel@perches.com> (raw)
In-Reply-To: <CAKwvOdkR_Ttfo7_JKUiZFVqr=Uh=4b05KCPCSuzwk=zaWtA2_Q@mail.gmail.com>

On Mon, 2020-10-19 at 12:42 -0700, Nick Desaulniers wrote:
> On Sat, Oct 17, 2020 at 10:43 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> > On Sat, Oct 17, 2020 at 09:09:28AM -0700, trix@redhat.com wrote:
> > > From: Tom Rix <trix@redhat.com>
> > > 
> > > This is a upcoming change to clean up a new warning treewide.
> > > I am wondering if the change could be one mega patch (see below) or
> > > normal patch per file about 100 patches or somewhere half way by collecting
> > > early acks.
> > 
> > Please break it up into one-patch-per-subsystem, like normal, and get it
> > merged that way.
> > 
> > Sending us a patch, without even a diffstat to review, isn't going to
> > get you very far...
> 
> Tom,
> If you're able to automate this cleanup, I suggest checking in a
> script that can be run on a directory.  Then for each subsystem you
> can say in your commit "I ran scripts/fix_whatever.py on this subdir."
>  Then others can help you drive the tree wide cleanup.  Then we can
> enable -Wunreachable-code-break either by default, or W=2 right now
> might be a good idea.
> 
> Ah, George (gbiv@, cc'ed), did an analysis recently of
> `-Wunreachable-code-loop-increment`, `-Wunreachable-code-break`, and
> `-Wunreachable-code-return` for Android userspace.  From the review:
> ```
> Spoilers: of these, it seems useful to turn on
> -Wunreachable-code-loop-increment and -Wunreachable-code-return by
> default for Android
> ...
> While these conventions about always having break arguably became
> obsolete when we enabled -Wfallthrough, my sample turned up zero
> potential bugs caught by this warning, and we'd need to put a lot of
> effort into getting a clean tree. So this warning doesn't seem to be
> worth it.
> ```
> Looks like there's an order of magnitude of `-Wunreachable-code-break`
> than the other two.
> 
> We probably should add all 3 to W=2 builds (wrapped in cc-option).
> I've filed https://github.com/ClangBuiltLinux/linux/issues/1180 to
> follow up on.

I suggest using W=1 as people that are doing cleanups
generally use that and not W=123 or any other style.

Every other use of W= is still quite noisy and these
code warnings are relatively trivially to fix up.


_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

WARNING: multiple messages have this Message-ID (diff)
From: Joe Perches <joe@perches.com>
To: Nick Desaulniers <ndesaulniers@google.com>, Tom Rix <trix@redhat.com>
Cc: alsa-devel@alsa-project.org,
	clang-built-linux <clang-built-linux@googlegroups.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	linux-iio@vger.kernel.org, nouveau@lists.freedesktop.org,
	storagedev@microchip.com,
	dri-devel <dri-devel@lists.freedesktop.org>,
	virtualization@lists.linux-foundation.org,
	keyrings@vger.kernel.org, linux-mtd@lists.infradead.org,
	ath10k@lists.infradead.org,
	linux-stm32@st-md-mailman.stormreply.com,
	usb-storage@lists.one-eyed-alien.net,
	linux-watchdog@vger.kernel.org, devel@driverdev.osuosl.org,
	linux-samsung-soc@vger.kernel.org, linux-scsi@vger.kernel.org,
	linux-nvdimm <linux-nvdimm@lists.01.org>,
	amd-gfx list <amd-gfx@lists.freedesktop.org>,
	linux-acpi@vger.kernel.org, intel-wired-lan@lists.osuosl.org,
	industrypack-devel@lists.sourceforge.net,
	linux-pci@vger.kernel.org, spice-devel@lists.freedesktop.org,
	MPT-FusionLinux.pdl@broadcom.com, linux-media@vger.kernel.org,
	linux-serial@vger.kernel.org, linux-nfc@lists.01.org,
	linux-pm@vger.kernel.org, linux-can@vger.kernel.org,
	linux-block@vger.kernel.org, linux-gpio@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	linux-amlogic@lists.infradead.org,
	openipmi-developer@lists.sourceforge.net,
	platform-driver-x86@vger.kernel.org,
	linux-integrity@vger.kernel.org,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	linux-edac@vger.kernel.org, George Burgess <gbiv@google.com>,
	Network Development <netdev@vger.kernel.org>,
	linux-usb@vger.kernel.org,
	linux-wireless <linux-wireless@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-security-module@vger.kernel.org,
	"open list:HARDWARE RANDOM NUMBER GENERATOR CORE"
	<linux-crypto@vger.kernel.org>,
	patches@opensource.cirrus.com, bpf <bpf@vger.kernel.org>,
	ocfs2-devel@oss.oracle.com, linux-power@fi.rohmeurope.com
Subject: Re: [RFC] treewide: cleanup unreachable breaks
Date: Tue, 20 Oct 2020 11:42:42 -0700	[thread overview]
Message-ID: <3bc5c2e3b3edc22a4d167ec807ecdaaf8dcda76d.camel@perches.com> (raw)
In-Reply-To: <CAKwvOdkR_Ttfo7_JKUiZFVqr=Uh=4b05KCPCSuzwk=zaWtA2_Q@mail.gmail.com>

On Mon, 2020-10-19 at 12:42 -0700, Nick Desaulniers wrote:
> On Sat, Oct 17, 2020 at 10:43 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> > On Sat, Oct 17, 2020 at 09:09:28AM -0700, trix@redhat.com wrote:
> > > From: Tom Rix <trix@redhat.com>
> > > 
> > > This is a upcoming change to clean up a new warning treewide.
> > > I am wondering if the change could be one mega patch (see below) or
> > > normal patch per file about 100 patches or somewhere half way by collecting
> > > early acks.
> > 
> > Please break it up into one-patch-per-subsystem, like normal, and get it
> > merged that way.
> > 
> > Sending us a patch, without even a diffstat to review, isn't going to
> > get you very far...
> 
> Tom,
> If you're able to automate this cleanup, I suggest checking in a
> script that can be run on a directory.  Then for each subsystem you
> can say in your commit "I ran scripts/fix_whatever.py on this subdir."
>  Then others can help you drive the tree wide cleanup.  Then we can
> enable -Wunreachable-code-break either by default, or W=2 right now
> might be a good idea.
> 
> Ah, George (gbiv@, cc'ed), did an analysis recently of
> `-Wunreachable-code-loop-increment`, `-Wunreachable-code-break`, and
> `-Wunreachable-code-return` for Android userspace.  From the review:
> ```
> Spoilers: of these, it seems useful to turn on
> -Wunreachable-code-loop-increment and -Wunreachable-code-return by
> default for Android
> ...
> While these conventions about always having break arguably became
> obsolete when we enabled -Wfallthrough, my sample turned up zero
> potential bugs caught by this warning, and we'd need to put a lot of
> effort into getting a clean tree. So this warning doesn't seem to be
> worth it.
> ```
> Looks like there's an order of magnitude of `-Wunreachable-code-break`
> than the other two.
> 
> We probably should add all 3 to W=2 builds (wrapped in cc-option).
> I've filed https://github.com/ClangBuiltLinux/linux/issues/1180 to
> follow up on.

I suggest using W=1 as people that are doing cleanups
generally use that and not W=123 or any other style.

Every other use of W= is still quite noisy and these
code warnings are relatively trivially to fix up.



WARNING: multiple messages have this Message-ID (diff)
From: Joe Perches <joe@perches.com>
To: Nick Desaulniers <ndesaulniers@google.com>, Tom Rix <trix@redhat.com>
Cc: alsa-devel@alsa-project.org,
	clang-built-linux <clang-built-linux@googlegroups.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	linux-iio@vger.kernel.org, nouveau@lists.freedesktop.org,
	storagedev@microchip.com,
	dri-devel <dri-devel@lists.freedesktop.org>,
	virtualization@lists.linux-foundation.org,
	keyrings@vger.kernel.org, linux-mtd@lists.infradead.org,
	ath10k@lists.infradead.org,
	linux-stm32@st-md-mailman.stormreply.com,
	usb-storage@lists.one-eyed-alien.net,
	linux-watchdog@vger.kernel.org, devel@driverdev.osuosl.org,
	linux-samsung-soc@vger.kernel.org, linux-scsi@vger.kernel.org,
	linux-nvdimm <linux-nvdimm@lists.01.org>,
	amd-gfx list <amd-gfx@lists.freedesktop.org>,
	linux-acpi@vger.kernel.org, intel-wired-lan@lists.osuosl.org,
	industrypack-devel@lists.sourceforge.net,
	linux-pci@vger.kernel.org, spice-devel@lists.freedesktop.org,
	MPT-FusionLinux.pdl@broadcom.com, linux-media@vger.kernel.org,
	linux-serial@vger.kernel.org, linux-nfc@lists.01.org,
	linux-pm@vger.kernel.org, linux-can@vger.kernel.org,
	linux-block@vger.kernel.org, linux-gpio@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	linux-amlogic@lists.infradead.org,
	openipmi-developer@lists.sourceforge.net,
	platform-driver-x86@vger.kernel.org,
	linux-integrity@vger.kernel.org,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	linux-edac@vger.kernel.org, George Burgess <gbiv@google.com>,
	Network Development <netdev@vger.kernel.org>,
	linux-usb@vger.kernel.org,
	linux-wireless <linux-wireless@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-security-module@vger.kernel.org,
	"open list:HARDWARE RANDOM NUMBER GENERATOR CORE"
	<linux-crypto@vger.kernel.org>,
	patches@opensource.cirrus.com, bpf <bpf@vger.kernel.org>,
	ocfs2-devel@oss.oracle.com, linux-power@fi.rohmeurope.com
Subject: Re: [RFC] treewide: cleanup unreachable breaks
Date: Tue, 20 Oct 2020 11:42:42 -0700	[thread overview]
Message-ID: <3bc5c2e3b3edc22a4d167ec807ecdaaf8dcda76d.camel@perches.com> (raw)
In-Reply-To: <CAKwvOdkR_Ttfo7_JKUiZFVqr=Uh=4b05KCPCSuzwk=zaWtA2_Q@mail.gmail.com>

On Mon, 2020-10-19 at 12:42 -0700, Nick Desaulniers wrote:
> On Sat, Oct 17, 2020 at 10:43 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> > On Sat, Oct 17, 2020 at 09:09:28AM -0700, trix@redhat.com wrote:
> > > From: Tom Rix <trix@redhat.com>
> > > 
> > > This is a upcoming change to clean up a new warning treewide.
> > > I am wondering if the change could be one mega patch (see below) or
> > > normal patch per file about 100 patches or somewhere half way by collecting
> > > early acks.
> > 
> > Please break it up into one-patch-per-subsystem, like normal, and get it
> > merged that way.
> > 
> > Sending us a patch, without even a diffstat to review, isn't going to
> > get you very far...
> 
> Tom,
> If you're able to automate this cleanup, I suggest checking in a
> script that can be run on a directory.  Then for each subsystem you
> can say in your commit "I ran scripts/fix_whatever.py on this subdir."
>  Then others can help you drive the tree wide cleanup.  Then we can
> enable -Wunreachable-code-break either by default, or W=2 right now
> might be a good idea.
> 
> Ah, George (gbiv@, cc'ed), did an analysis recently of
> `-Wunreachable-code-loop-increment`, `-Wunreachable-code-break`, and
> `-Wunreachable-code-return` for Android userspace.  From the review:
> ```
> Spoilers: of these, it seems useful to turn on
> -Wunreachable-code-loop-increment and -Wunreachable-code-return by
> default for Android
> ...
> While these conventions about always having break arguably became
> obsolete when we enabled -Wfallthrough, my sample turned up zero
> potential bugs caught by this warning, and we'd need to put a lot of
> effort into getting a clean tree. So this warning doesn't seem to be
> worth it.
> ```
> Looks like there's an order of magnitude of `-Wunreachable-code-break`
> than the other two.
> 
> We probably should add all 3 to W=2 builds (wrapped in cc-option).
> I've filed https://github.com/ClangBuiltLinux/linux/issues/1180 to
> follow up on.

I suggest using W=1 as people that are doing cleanups
generally use that and not W=123 or any other style.

Every other use of W= is still quite noisy and these
code warnings are relatively trivially to fix up.



______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

WARNING: multiple messages have this Message-ID (diff)
From: Joe Perches <joe@perches.com>
To: Nick Desaulniers <ndesaulniers@google.com>, Tom Rix <trix@redhat.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	linux-edac@vger.kernel.org, linux-acpi@vger.kernel.org,
	linux-pm@vger.kernel.org, xen-devel@lists.xenproject.org,
	linux-block@vger.kernel.org,
	openipmi-developer@lists.sourceforge.net,
	"open list:HARDWARE RANDOM NUMBER GENERATOR CORE"
	<linux-crypto@vger.kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	linux-power@fi.rohmeurope.com, linux-gpio@vger.kernel.org,
	amd-gfx list <amd-gfx@lists.freedesktop.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	nouveau@lists.freedesktop.org,
	virtualization@lists.linux-foundation.org,
	spice-devel@lists.freedesktop.org, linux-iio@vger.kernel.org,
	linux-amlogic@lists.infradead.org,
	industrypack-devel@lists.sourceforge.net,
	linux-media@vger.kernel.org, MPT-FusionLinux.pdl@broadcom.
Subject: Re: [RFC] treewide: cleanup unreachable breaks
Date: Tue, 20 Oct 2020 11:42:42 -0700	[thread overview]
Message-ID: <3bc5c2e3b3edc22a4d167ec807ecdaaf8dcda76d.camel@perches.com> (raw)
In-Reply-To: <CAKwvOdkR_Ttfo7_JKUiZFVqr=Uh=4b05KCPCSuzwk=zaWtA2_Q@mail.gmail.com>

On Mon, 2020-10-19 at 12:42 -0700, Nick Desaulniers wrote:
> On Sat, Oct 17, 2020 at 10:43 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> > On Sat, Oct 17, 2020 at 09:09:28AM -0700, trix@redhat.com wrote:
> > > From: Tom Rix <trix@redhat.com>
> > > 
> > > This is a upcoming change to clean up a new warning treewide.
> > > I am wondering if the change could be one mega patch (see below) or
> > > normal patch per file about 100 patches or somewhere half way by collecting
> > > early acks.
> > 
> > Please break it up into one-patch-per-subsystem, like normal, and get it
> > merged that way.
> > 
> > Sending us a patch, without even a diffstat to review, isn't going to
> > get you very far...
> 
> Tom,
> If you're able to automate this cleanup, I suggest checking in a
> script that can be run on a directory.  Then for each subsystem you
> can say in your commit "I ran scripts/fix_whatever.py on this subdir."
>  Then others can help you drive the tree wide cleanup.  Then we can
> enable -Wunreachable-code-break either by default, or W=2 right now
> might be a good idea.
> 
> Ah, George (gbiv@, cc'ed), did an analysis recently of
> `-Wunreachable-code-loop-increment`, `-Wunreachable-code-break`, and
> `-Wunreachable-code-return` for Android userspace.  From the review:
> ```
> Spoilers: of these, it seems useful to turn on
> -Wunreachable-code-loop-increment and -Wunreachable-code-return by
> default for Android
> ...
> While these conventions about always having break arguably became
> obsolete when we enabled -Wfallthrough, my sample turned up zero
> potential bugs caught by this warning, and we'd need to put a lot of
> effort into getting a clean tree. So this warning doesn't seem to be
> worth it.
> ```
> Looks like there's an order of magnitude of `-Wunreachable-code-break`
> than the other two.
> 
> We probably should add all 3 to W=2 builds (wrapped in cc-option).
> I've filed https://github.com/ClangBuiltLinux/linux/issues/1180 to
> follow up on.

I suggest using W=1 as people that are doing cleanups
generally use that and not W=123 or any other style.

Every other use of W= is still quite noisy and these
code warnings are relatively trivially to fix up.

WARNING: multiple messages have this Message-ID (diff)
From: Joe Perches <joe@perches.com>
To: Nick Desaulniers <ndesaulniers@google.com>, Tom Rix <trix@redhat.com>
Cc: alsa-devel@alsa-project.org,
	clang-built-linux <clang-built-linux@googlegroups.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	linux-iio@vger.kernel.org, nouveau@lists.freedesktop.org,
	storagedev@microchip.com,
	dri-devel <dri-devel@lists.freedesktop.org>,
	virtualization@lists.linux-foundation.org,
	keyrings@vger.kernel.org, linux-mtd@lists.infradead.org,
	ath10k@lists.infradead.org,
	linux-stm32@st-md-mailman.stormreply.com,
	usb-storage@lists.one-eyed-alien.net,
	linux-watchdog@vger.kernel.org, devel@driverdev.osuosl.org,
	linux-samsung-soc@vger.kernel.org, linux-scsi@vger.kernel.org,
	linux-nvdimm <linux-nvdimm@lists.01.org>,
	amd-gfx list <amd-gfx@lists.freedesktop.org>,
	linux-acpi@vger.kernel.org, intel-wired-lan@lists.osuosl.org,
	industrypack-devel@lists.sourceforge.net,
	linux-pci@vger.kernel.org, spice-devel@lists.freedesktop.org,
	MPT-FusionLinux.pdl@broadcom.com, linux-media@vger.kernel.org,
	linux-serial@vger.kernel.org, linux-nfc@lists.01.org,
	linux-pm@vger.kernel.org, linux-can@vger.kernel.org,
	linux-block@vger.kernel.org, linux-gpio@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	linux-amlogic@lists.infradead.org,
	openipmi-developer@lists.sourceforge.net,
	platform-driver-x86@vger.kernel.org,
	linux-integrity@vger.kernel.org,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	linux-edac@vger.kernel.org, George Burgess <gbiv@google.com>,
	Network Development <netdev@vger.kernel.org>,
	linux-usb@vger.kernel.org,
	linux-wireless <linux-wireless@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-security-module@vger.kernel.org,
	"open list:HARDWARE RANDOM NUMBER GENERATOR CORE"
	<linux-crypto@vger.kernel.org>,
	patches@opensource.cirrus.com, bpf <bpf@vger.kernel.org>,
	ocfs2-devel@oss.oracle.com, linux-power@fi.rohmeurope.com
Subject: Re: [RFC] treewide: cleanup unreachable breaks
Date: Tue, 20 Oct 2020 11:42:42 -0700	[thread overview]
Message-ID: <3bc5c2e3b3edc22a4d167ec807ecdaaf8dcda76d.camel@perches.com> (raw)
In-Reply-To: <CAKwvOdkR_Ttfo7_JKUiZFVqr=Uh=4b05KCPCSuzwk=zaWtA2_Q@mail.gmail.com>

On Mon, 2020-10-19 at 12:42 -0700, Nick Desaulniers wrote:
> On Sat, Oct 17, 2020 at 10:43 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> > On Sat, Oct 17, 2020 at 09:09:28AM -0700, trix@redhat.com wrote:
> > > From: Tom Rix <trix@redhat.com>
> > > 
> > > This is a upcoming change to clean up a new warning treewide.
> > > I am wondering if the change could be one mega patch (see below) or
> > > normal patch per file about 100 patches or somewhere half way by collecting
> > > early acks.
> > 
> > Please break it up into one-patch-per-subsystem, like normal, and get it
> > merged that way.
> > 
> > Sending us a patch, without even a diffstat to review, isn't going to
> > get you very far...
> 
> Tom,
> If you're able to automate this cleanup, I suggest checking in a
> script that can be run on a directory.  Then for each subsystem you
> can say in your commit "I ran scripts/fix_whatever.py on this subdir."
>  Then others can help you drive the tree wide cleanup.  Then we can
> enable -Wunreachable-code-break either by default, or W=2 right now
> might be a good idea.
> 
> Ah, George (gbiv@, cc'ed), did an analysis recently of
> `-Wunreachable-code-loop-increment`, `-Wunreachable-code-break`, and
> `-Wunreachable-code-return` for Android userspace.  From the review:
> ```
> Spoilers: of these, it seems useful to turn on
> -Wunreachable-code-loop-increment and -Wunreachable-code-return by
> default for Android
> ...
> While these conventions about always having break arguably became
> obsolete when we enabled -Wfallthrough, my sample turned up zero
> potential bugs caught by this warning, and we'd need to put a lot of
> effort into getting a clean tree. So this warning doesn't seem to be
> worth it.
> ```
> Looks like there's an order of magnitude of `-Wunreachable-code-break`
> than the other two.
> 
> We probably should add all 3 to W=2 builds (wrapped in cc-option).
> I've filed https://github.com/ClangBuiltLinux/linux/issues/1180 to
> follow up on.

I suggest using W=1 as people that are doing cleanups
generally use that and not W=123 or any other style.

Every other use of W= is still quite noisy and these
code warnings are relatively trivially to fix up.


_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

WARNING: multiple messages have this Message-ID (diff)
From: Joe Perches <joe@perches.com>
To: Nick Desaulniers <ndesaulniers@google.com>, Tom Rix <trix@redhat.com>
Cc: alsa-devel@alsa-project.org,
	clang-built-linux <clang-built-linux@googlegroups.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	linux-iio@vger.kernel.org, nouveau@lists.freedesktop.org,
	storagedev@microchip.com,
	dri-devel <dri-devel@lists.freedesktop.org>,
	virtualization@lists.linux-foundation.org,
	keyrings@vger.kernel.org, linux-mtd@lists.infradead.org,
	ath10k@lists.infradead.org,
	linux-stm32@st-md-mailman.stormreply.com,
	usb-storage@lists.one-eyed-alien.net,
	linux-watchdog@vger.kernel.org, devel@driverdev.osuosl.org,
	linux-samsung-soc@vger.kernel.org, linux-scsi@vger.kernel.org,
	linux-nvdimm <linux-nvdimm@lists.01.org>,
	amd-gfx list <amd-gfx@lists.freedesktop.org>,
	linux-acpi@vger.kernel.org, intel-wired-lan@lists.osuosl.org,
	industrypack-devel@lists.sourceforge.net,
	linux-pci@vger.kernel.org, spice-devel@lists.freedesktop.org,
	MPT-FusionLinux.pdl@broadcom.com, linux-media@vger.kernel.org,
	linux-serial@vger.kernel.org, linux-nfc@lists.01.org,
	linux-pm@vger.kernel.org, linux-can@vger.kernel.org,
	linux-block@vger.kernel.org, linux-gpio@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	linux-amlogic@lists.infradead.org,
	openipmi-developer@lists.sourceforge.net,
	platform-driver-x86@vger.kernel.org,
	linux-integrity@vger.kernel.org,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	linux-edac@vger.kernel.org, George Burgess <gbiv@google.com>,
	Network Development <netdev@vger.kernel.org>,
	linux-usb@vger.kernel.org,
	linux-wireless <linux-wireless@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-security-module@vger.kernel.org,
	"open list:HARDWARE RANDOM NUMBER GENERATOR CORE"
	<linux-crypto@vger.kernel.org>,
	patches@opensource.cirrus.com, bpf <bpf@vger.kernel.org>,
	ocfs2-devel@oss.oracle.com, linux-power@fi.rohmeurope.com
Subject: Re: [RFC] treewide: cleanup unreachable breaks
Date: Tue, 20 Oct 2020 11:42:42 -0700	[thread overview]
Message-ID: <3bc5c2e3b3edc22a4d167ec807ecdaaf8dcda76d.camel@perches.com> (raw)
In-Reply-To: <CAKwvOdkR_Ttfo7_JKUiZFVqr=Uh=4b05KCPCSuzwk=zaWtA2_Q@mail.gmail.com>

On Mon, 2020-10-19 at 12:42 -0700, Nick Desaulniers wrote:
> On Sat, Oct 17, 2020 at 10:43 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> > On Sat, Oct 17, 2020 at 09:09:28AM -0700, trix@redhat.com wrote:
> > > From: Tom Rix <trix@redhat.com>
> > > 
> > > This is a upcoming change to clean up a new warning treewide.
> > > I am wondering if the change could be one mega patch (see below) or
> > > normal patch per file about 100 patches or somewhere half way by collecting
> > > early acks.
> > 
> > Please break it up into one-patch-per-subsystem, like normal, and get it
> > merged that way.
> > 
> > Sending us a patch, without even a diffstat to review, isn't going to
> > get you very far...
> 
> Tom,
> If you're able to automate this cleanup, I suggest checking in a
> script that can be run on a directory.  Then for each subsystem you
> can say in your commit "I ran scripts/fix_whatever.py on this subdir."
>  Then others can help you drive the tree wide cleanup.  Then we can
> enable -Wunreachable-code-break either by default, or W=2 right now
> might be a good idea.
> 
> Ah, George (gbiv@, cc'ed), did an analysis recently of
> `-Wunreachable-code-loop-increment`, `-Wunreachable-code-break`, and
> `-Wunreachable-code-return` for Android userspace.  From the review:
> ```
> Spoilers: of these, it seems useful to turn on
> -Wunreachable-code-loop-increment and -Wunreachable-code-return by
> default for Android
> ...
> While these conventions about always having break arguably became
> obsolete when we enabled -Wfallthrough, my sample turned up zero
> potential bugs caught by this warning, and we'd need to put a lot of
> effort into getting a clean tree. So this warning doesn't seem to be
> worth it.
> ```
> Looks like there's an order of magnitude of `-Wunreachable-code-break`
> than the other two.
> 
> We probably should add all 3 to W=2 builds (wrapped in cc-option).
> I've filed https://github.com/ClangBuiltLinux/linux/issues/1180 to
> follow up on.

I suggest using W=1 as people that are doing cleanups
generally use that and not W=123 or any other style.

Every other use of W= is still quite noisy and these
code warnings are relatively trivially to fix up.


_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

WARNING: multiple messages have this Message-ID (diff)
From: Joe Perches <joe@perches.com>
To: Nick Desaulniers <ndesaulniers@google.com>, Tom Rix <trix@redhat.com>
Cc: alsa-devel@alsa-project.org,
	clang-built-linux <clang-built-linux@googlegroups.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	linux-iio@vger.kernel.org, nouveau@lists.freedesktop.org,
	storagedev@microchip.com,
	dri-devel <dri-devel@lists.freedesktop.org>,
	virtualization@lists.linux-foundation.org,
	keyrings@vger.kernel.org, linux-mtd@lists.infradead.org,
	ath10k@lists.infradead.org,
	linux-stm32@st-md-mailman.stormreply.com,
	usb-storage@lists.one-eyed-alien.net,
	linux-watchdog@vger.kernel.org, devel@driverdev.osuosl.org,
	linux-samsung-soc@vger.kernel.org, linux-scsi@vger.kernel.org,
	linux-nvdimm <linux-nvdimm@lists.01.org>,
	amd-gfx list <amd-gfx@lists.freedesktop.org>,
	linux-acpi@vger.kernel.org, intel-wired-lan@lists.osuosl.org,
	industrypack-devel@lists.sourceforge.net,
	linux-pci@vger.kernel.org, spice-devel@lists.freedesktop.org,
	MPT-FusionLinux.pdl@broadcom.com, linux-media@vger.kernel.org,
	linux-serial@vger.kernel.org, linux-nfc@lists.01.org,
	linux-pm@vger.kernel.org, linux-can@vger.kernel.org,
	linux-block@vger.kernel.org, linux-gpio@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	linux-amlogic@lists.infradead.org,
	openipmi-developer@lists.sourceforge.net,
	platform-driver-x86@vger.kernel.org,
	linux-integrity@vger.kernel.org,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	linux-edac@vger.kernel.org, George Burgess <gbiv@google.com>,
	Network Development <netdev@vger.kernel.org>,
	linux-usb@vger.kernel.org,
	linux-wireless <linux-wireless@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-security-module@vger.kernel.org,
	"open list:HARDWARE RANDOM NUMBER GENERATOR CORE"
	<linux-crypto@vger.kernel.org>,
	patches@opensource.cirrus.com, bpf <bpf@vger.kernel.org>,
	ocfs2-devel@oss.oracle.com, linux-power@fi.rohmeurope.com
Subject: Re: [RFC] treewide: cleanup unreachable breaks
Date: Tue, 20 Oct 2020 11:42:42 -0700	[thread overview]
Message-ID: <3bc5c2e3b3edc22a4d167ec807ecdaaf8dcda76d.camel@perches.com> (raw)
In-Reply-To: <CAKwvOdkR_Ttfo7_JKUiZFVqr=Uh=4b05KCPCSuzwk=zaWtA2_Q@mail.gmail.com>

On Mon, 2020-10-19 at 12:42 -0700, Nick Desaulniers wrote:
> On Sat, Oct 17, 2020 at 10:43 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> > On Sat, Oct 17, 2020 at 09:09:28AM -0700, trix@redhat.com wrote:
> > > From: Tom Rix <trix@redhat.com>
> > > 
> > > This is a upcoming change to clean up a new warning treewide.
> > > I am wondering if the change could be one mega patch (see below) or
> > > normal patch per file about 100 patches or somewhere half way by collecting
> > > early acks.
> > 
> > Please break it up into one-patch-per-subsystem, like normal, and get it
> > merged that way.
> > 
> > Sending us a patch, without even a diffstat to review, isn't going to
> > get you very far...
> 
> Tom,
> If you're able to automate this cleanup, I suggest checking in a
> script that can be run on a directory.  Then for each subsystem you
> can say in your commit "I ran scripts/fix_whatever.py on this subdir."
>  Then others can help you drive the tree wide cleanup.  Then we can
> enable -Wunreachable-code-break either by default, or W=2 right now
> might be a good idea.
> 
> Ah, George (gbiv@, cc'ed), did an analysis recently of
> `-Wunreachable-code-loop-increment`, `-Wunreachable-code-break`, and
> `-Wunreachable-code-return` for Android userspace.  From the review:
> ```
> Spoilers: of these, it seems useful to turn on
> -Wunreachable-code-loop-increment and -Wunreachable-code-return by
> default for Android
> ...
> While these conventions about always having break arguably became
> obsolete when we enabled -Wfallthrough, my sample turned up zero
> potential bugs caught by this warning, and we'd need to put a lot of
> effort into getting a clean tree. So this warning doesn't seem to be
> worth it.
> ```
> Looks like there's an order of magnitude of `-Wunreachable-code-break`
> than the other two.
> 
> We probably should add all 3 to W=2 builds (wrapped in cc-option).
> I've filed https://github.com/ClangBuiltLinux/linux/issues/1180 to
> follow up on.

I suggest using W=1 as people that are doing cleanups
generally use that and not W=123 or any other style.

Every other use of W= is still quite noisy and these
code warnings are relatively trivially to fix up.



_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

WARNING: multiple messages have this Message-ID (diff)
From: Joe Perches <joe@perches.com>
To: Nick Desaulniers <ndesaulniers@google.com>, Tom Rix <trix@redhat.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	linux-edac@vger.kernel.org,  linux-acpi@vger.kernel.org,
	linux-pm@vger.kernel.org,  xen-devel@lists.xenproject.org,
	linux-block@vger.kernel.org,
	 openipmi-developer@lists.sourceforge.net,
	"open list:HARDWARE RANDOM NUMBER GENERATOR CORE"
	<linux-crypto@vger.kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	 linux-power@fi.rohmeurope.com, linux-gpio@vger.kernel.org,
	amd-gfx list <amd-gfx@lists.freedesktop.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	 nouveau@lists.freedesktop.org,
	virtualization@lists.linux-foundation.org,
	 spice-devel@lists.freedesktop.org, linux-iio@vger.kernel.org,
	 linux-amlogic@lists.infradead.org,
	industrypack-devel@lists.sourceforge.net,
	 linux-media@vger.kernel.org, MPT-FusionLinux.pdl@broadcom.com,
	 linux-scsi@vger.kernel.org, linux-mtd@lists.infradead.org,
	 linux-can@vger.kernel.org,
	Network Development <netdev@vger.kernel.org>,
	 intel-wired-lan@lists.osuosl.org, ath10k@lists.infradead.org,
	linux-wireless <linux-wireless@vger.kernel.org>,
	linux-stm32@st-md-mailman.stormreply.com, linux-nfc@lists.01.org,
	linux-nvdimm <linux-nvdimm@lists.01.org>,
	 linux-pci@vger.kernel.org, linux-samsung-soc@vger.kernel.org,
	 platform-driver-x86@vger.kernel.org,
	patches@opensource.cirrus.com,  storagedev@microchip.com,
	devel@driverdev.osuosl.org,  linux-serial@vger.kernel.org,
	linux-usb@vger.kernel.org,  usb-storage@lists.one-eyed-alien.net,
	linux-watchdog@vger.kernel.org,  ocfs2-devel@oss.oracle.com,
	bpf <bpf@vger.kernel.org>,
	 linux-integrity@vger.kernel.org,
	linux-security-module@vger.kernel.org,  keyrings@vger.kernel.org,
	alsa-devel@alsa-project.org,
	clang-built-linux <clang-built-linux@googlegroups.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	George Burgess <gbiv@google.com>
Subject: Re: [RFC] treewide: cleanup unreachable breaks
Date: Tue, 20 Oct 2020 11:42:42 -0700	[thread overview]
Message-ID: <3bc5c2e3b3edc22a4d167ec807ecdaaf8dcda76d.camel@perches.com> (raw)
In-Reply-To: <CAKwvOdkR_Ttfo7_JKUiZFVqr=Uh=4b05KCPCSuzwk=zaWtA2_Q@mail.gmail.com>

On Mon, 2020-10-19 at 12:42 -0700, Nick Desaulniers wrote:
> On Sat, Oct 17, 2020 at 10:43 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> > On Sat, Oct 17, 2020 at 09:09:28AM -0700, trix@redhat.com wrote:
> > > From: Tom Rix <trix@redhat.com>
> > > 
> > > This is a upcoming change to clean up a new warning treewide.
> > > I am wondering if the change could be one mega patch (see below) or
> > > normal patch per file about 100 patches or somewhere half way by collecting
> > > early acks.
> > 
> > Please break it up into one-patch-per-subsystem, like normal, and get it
> > merged that way.
> > 
> > Sending us a patch, without even a diffstat to review, isn't going to
> > get you very far...
> 
> Tom,
> If you're able to automate this cleanup, I suggest checking in a
> script that can be run on a directory.  Then for each subsystem you
> can say in your commit "I ran scripts/fix_whatever.py on this subdir."
>  Then others can help you drive the tree wide cleanup.  Then we can
> enable -Wunreachable-code-break either by default, or W=2 right now
> might be a good idea.
> 
> Ah, George (gbiv@, cc'ed), did an analysis recently of
> `-Wunreachable-code-loop-increment`, `-Wunreachable-code-break`, and
> `-Wunreachable-code-return` for Android userspace.  From the review:
> ```
> Spoilers: of these, it seems useful to turn on
> -Wunreachable-code-loop-increment and -Wunreachable-code-return by
> default for Android
> ...
> While these conventions about always having break arguably became
> obsolete when we enabled -Wfallthrough, my sample turned up zero
> potential bugs caught by this warning, and we'd need to put a lot of
> effort into getting a clean tree. So this warning doesn't seem to be
> worth it.
> ```
> Looks like there's an order of magnitude of `-Wunreachable-code-break`
> than the other two.
> 
> We probably should add all 3 to W=2 builds (wrapped in cc-option).
> I've filed https://github.com/ClangBuiltLinux/linux/issues/1180 to
> follow up on.

I suggest using W=1 as people that are doing cleanups
generally use that and not W=123 or any other style.

Every other use of W= is still quite noisy and these
code warnings are relatively trivially to fix up.




WARNING: multiple messages have this Message-ID (diff)
From: Joe Perches <joe@perches.com>
To: Nick Desaulniers <ndesaulniers@google.com>, Tom Rix <trix@redhat.com>
Cc: alsa-devel@alsa-project.org,
	clang-built-linux <clang-built-linux@googlegroups.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	linux-iio@vger.kernel.org, nouveau@lists.freedesktop.org,
	storagedev@microchip.com,
	dri-devel <dri-devel@lists.freedesktop.org>,
	virtualization@lists.linux-foundation.org,
	keyrings@vger.kernel.org, linux-mtd@lists.infradead.org,
	ath10k@lists.infradead.org,
	linux-stm32@st-md-mailman.stormreply.com,
	usb-storage@lists.one-eyed-alien.net,
	linux-watchdog@vger.kernel.org, devel@driverdev.osuosl.org,
	linux-samsung-soc@vger.kernel.org, linux-scsi@vger.kernel.org,
	linux-nvdimm <linux-nvdimm@lists.01.org>,
	amd-gfx list <amd-gfx@lists.freedesktop.org>,
	linux-acpi@vger.kernel.org, intel-wired-lan@lists.osuosl.org,
	industrypack-devel@lists.sourceforge.net,
	linux-pci@vger.kernel.org, spice-devel@lists.freedesktop.org,
	MPT-FusionLinux.pdl@broadcom.com, linux-media@vger.kernel.org,
	linux-serial@vger.kernel.org, linux-nfc@lists.01.org,
	linux-pm@vger.kernel.org, linux-can@vger.kernel.org,
	linux-block@vger.kernel.org, linux-gpio@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	linux-amlogic@lists.infradead.org,
	openipmi-developer@lists.sourceforge.net,
	platform-driver-x86@vger.kernel.org,
	linux-integrity@vger.kernel.org,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	linux-edac@vger.kernel.org, George Burgess <gbiv@google.com>,
	Network Development <netdev@vger.kernel.org>,
	linux-usb@vger.kernel.org,
	linux-wireless <linux-wireless@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-security-module@vger.kernel.org,
	"open list:HARDWARE RANDOM NUMBER GENERATOR CORE"
	<linux-crypto@vger.kernel.org>,
	patches@opensource.cirrus.com, bpf <bpf@vger.kernel.org>,
	ocfs2-devel@oss.oracle.com, linux-power@fi.rohmeurope.com
Subject: Re: [RFC] treewide: cleanup unreachable breaks
Date: Tue, 20 Oct 2020 11:42:42 -0700	[thread overview]
Message-ID: <3bc5c2e3b3edc22a4d167ec807ecdaaf8dcda76d.camel@perches.com> (raw)
In-Reply-To: <CAKwvOdkR_Ttfo7_JKUiZFVqr=Uh=4b05KCPCSuzwk=zaWtA2_Q@mail.gmail.com>

On Mon, 2020-10-19 at 12:42 -0700, Nick Desaulniers wrote:
> On Sat, Oct 17, 2020 at 10:43 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> > On Sat, Oct 17, 2020 at 09:09:28AM -0700, trix@redhat.com wrote:
> > > From: Tom Rix <trix@redhat.com>
> > > 
> > > This is a upcoming change to clean up a new warning treewide.
> > > I am wondering if the change could be one mega patch (see below) or
> > > normal patch per file about 100 patches or somewhere half way by collecting
> > > early acks.
> > 
> > Please break it up into one-patch-per-subsystem, like normal, and get it
> > merged that way.
> > 
> > Sending us a patch, without even a diffstat to review, isn't going to
> > get you very far...
> 
> Tom,
> If you're able to automate this cleanup, I suggest checking in a
> script that can be run on a directory.  Then for each subsystem you
> can say in your commit "I ran scripts/fix_whatever.py on this subdir."
>  Then others can help you drive the tree wide cleanup.  Then we can
> enable -Wunreachable-code-break either by default, or W=2 right now
> might be a good idea.
> 
> Ah, George (gbiv@, cc'ed), did an analysis recently of
> `-Wunreachable-code-loop-increment`, `-Wunreachable-code-break`, and
> `-Wunreachable-code-return` for Android userspace.  From the review:
> ```
> Spoilers: of these, it seems useful to turn on
> -Wunreachable-code-loop-increment and -Wunreachable-code-return by
> default for Android
> ...
> While these conventions about always having break arguably became
> obsolete when we enabled -Wfallthrough, my sample turned up zero
> potential bugs caught by this warning, and we'd need to put a lot of
> effort into getting a clean tree. So this warning doesn't seem to be
> worth it.
> ```
> Looks like there's an order of magnitude of `-Wunreachable-code-break`
> than the other two.
> 
> We probably should add all 3 to W=2 builds (wrapped in cc-option).
> I've filed https://github.com/ClangBuiltLinux/linux/issues/1180 to
> follow up on.

I suggest using W=1 as people that are doing cleanups
generally use that and not W=123 or any other style.

Every other use of W= is still quite noisy and these
code warnings are relatively trivially to fix up.


_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

WARNING: multiple messages have this Message-ID (diff)
From: Joe Perches <joe@perches.com>
To: Nick Desaulniers <ndesaulniers@google.com>, Tom Rix <trix@redhat.com>
Cc: alsa-devel@alsa-project.org,
	clang-built-linux <clang-built-linux@googlegroups.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	linux-iio@vger.kernel.org, nouveau@lists.freedesktop.org,
	storagedev@microchip.com,
	dri-devel <dri-devel@lists.freedesktop.org>,
	virtualization@lists.linux-foundation.org,
	keyrings@vger.kernel.org, linux-mtd@lists.infradead.org,
	ath10k@lists.infradead.org,
	linux-stm32@st-md-mailman.stormreply.com,
	usb-storage@lists.one-eyed-alien.net,
	linux-watchdog@vger.kernel.org, devel@driverdev.osuosl.org,
	linux-samsung-soc@vger.kernel.org, linux-scsi@vger.kernel.org,
	linux-nvdimm <linux-nvdimm@lists.01.org>,
	amd-gfx list <amd-gfx@lists.freedesktop.org>,
	linux-acpi@vger.kernel.org, intel-wired-lan@lists.osuosl.org,
	industrypack-devel@lists.sourceforge.net,
	linux-pci@vger.kernel.org, spice-devel@lists.freedesktop.org,
	MPT-FusionLinux.pdl@broadcom.com, linux-media@vger.kernel.org,
	linux-serial@vger.kernel.org, linux-nfc@lists.01.org,
	linux-pm@vger.kernel.org, linux-can@vger.kernel.org,
	linux-block@vger.kernel.org, linux-gpio@vger.kernel.org,
	xen-devel@lists.xenproject.org,
	linux-amlogic@lists.infradead.org,
	openipmi-developer@lists.sourceforge.net,
	platform-driver-x86@vger.kernel.org,
	linux-integrity@vger.kernel.org,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	linux-edac@vger.kernel.org, George Burgess <gbiv@google.com>,
	Network Development <netdev@vger.kernel.org>,
	linux-usb@vger.kernel.org,
	linux-wireless <linux-wireless@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-security-module@vger.kernel.org,
	"open list:HARDWARE RANDOM NUMBER GENERATOR CORE"
	<linux-crypto@vger.kernel.org>,
	patches@opensource.cirrus.com, bpf <bpf@vger.kernel.org>,
	ocfs2-devel@oss.oracle.com, linux-power@fi.rohmeurope.com
Subject: Re: [RFC] treewide: cleanup unreachable breaks
Date: Tue, 20 Oct 2020 11:42:42 -0700	[thread overview]
Message-ID: <3bc5c2e3b3edc22a4d167ec807ecdaaf8dcda76d.camel@perches.com> (raw)
In-Reply-To: <CAKwvOdkR_Ttfo7_JKUiZFVqr=Uh=4b05KCPCSuzwk=zaWtA2_Q@mail.gmail.com>

On Mon, 2020-10-19 at 12:42 -0700, Nick Desaulniers wrote:
> On Sat, Oct 17, 2020 at 10:43 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> > On Sat, Oct 17, 2020 at 09:09:28AM -0700, trix@redhat.com wrote:
> > > From: Tom Rix <trix@redhat.com>
> > > 
> > > This is a upcoming change to clean up a new warning treewide.
> > > I am wondering if the change could be one mega patch (see below) or
> > > normal patch per file about 100 patches or somewhere half way by collecting
> > > early acks.
> > 
> > Please break it up into one-patch-per-subsystem, like normal, and get it
> > merged that way.
> > 
> > Sending us a patch, without even a diffstat to review, isn't going to
> > get you very far...
> 
> Tom,
> If you're able to automate this cleanup, I suggest checking in a
> script that can be run on a directory.  Then for each subsystem you
> can say in your commit "I ran scripts/fix_whatever.py on this subdir."
>  Then others can help you drive the tree wide cleanup.  Then we can
> enable -Wunreachable-code-break either by default, or W=2 right now
> might be a good idea.
> 
> Ah, George (gbiv@, cc'ed), did an analysis recently of
> `-Wunreachable-code-loop-increment`, `-Wunreachable-code-break`, and
> `-Wunreachable-code-return` for Android userspace.  From the review:
> ```
> Spoilers: of these, it seems useful to turn on
> -Wunreachable-code-loop-increment and -Wunreachable-code-return by
> default for Android
> ...
> While these conventions about always having break arguably became
> obsolete when we enabled -Wfallthrough, my sample turned up zero
> potential bugs caught by this warning, and we'd need to put a lot of
> effort into getting a clean tree. So this warning doesn't seem to be
> worth it.
> ```
> Looks like there's an order of magnitude of `-Wunreachable-code-break`
> than the other two.
> 
> We probably should add all 3 to W=2 builds (wrapped in cc-option).
> I've filed https://github.com/ClangBuiltLinux/linux/issues/1180 to
> follow up on.

I suggest using W=1 as people that are doing cleanups
generally use that and not W=123 or any other style.

Every other use of W= is still quite noisy and these
code warnings are relatively trivially to fix up.



_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

WARNING: multiple messages have this Message-ID (diff)
From: Joe Perches <joe@perches.com>
To: intel-wired-lan@osuosl.org
Subject: [Intel-wired-lan] [RFC] treewide: cleanup unreachable breaks
Date: Tue, 20 Oct 2020 11:42:42 -0700	[thread overview]
Message-ID: <3bc5c2e3b3edc22a4d167ec807ecdaaf8dcda76d.camel@perches.com> (raw)
In-Reply-To: <CAKwvOdkR_Ttfo7_JKUiZFVqr=Uh=4b05KCPCSuzwk=zaWtA2_Q@mail.gmail.com>

On Mon, 2020-10-19 at 12:42 -0700, Nick Desaulniers wrote:
> On Sat, Oct 17, 2020 at 10:43 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> > On Sat, Oct 17, 2020 at 09:09:28AM -0700, trix at redhat.com wrote:
> > > From: Tom Rix <trix@redhat.com>
> > > 
> > > This is a upcoming change to clean up a new warning treewide.
> > > I am wondering if the change could be one mega patch (see below) or
> > > normal patch per file about 100 patches or somewhere half way by collecting
> > > early acks.
> > 
> > Please break it up into one-patch-per-subsystem, like normal, and get it
> > merged that way.
> > 
> > Sending us a patch, without even a diffstat to review, isn't going to
> > get you very far...
> 
> Tom,
> If you're able to automate this cleanup, I suggest checking in a
> script that can be run on a directory.  Then for each subsystem you
> can say in your commit "I ran scripts/fix_whatever.py on this subdir."
>  Then others can help you drive the tree wide cleanup.  Then we can
> enable -Wunreachable-code-break either by default, or W=2 right now
> might be a good idea.
> 
> Ah, George (gbiv@, cc'ed), did an analysis recently of
> `-Wunreachable-code-loop-increment`, `-Wunreachable-code-break`, and
> `-Wunreachable-code-return` for Android userspace.  From the review:
> ```
> Spoilers: of these, it seems useful to turn on
> -Wunreachable-code-loop-increment and -Wunreachable-code-return by
> default for Android
> ...
> While these conventions about always having break arguably became
> obsolete when we enabled -Wfallthrough, my sample turned up zero
> potential bugs caught by this warning, and we'd need to put a lot of
> effort into getting a clean tree. So this warning doesn't seem to be
> worth it.
> ```
> Looks like there's an order of magnitude of `-Wunreachable-code-break`
> than the other two.
> 
> We probably should add all 3 to W=2 builds (wrapped in cc-option).
> I've filed https://github.com/ClangBuiltLinux/linux/issues/1180 to
> follow up on.

I suggest using W=1 as people that are doing cleanups
generally use that and not W=123 or any other style.

Every other use of W= is still quite noisy and these
code warnings are relatively trivially to fix up.



  parent reply	other threads:[~2020-10-20 18:42 UTC|newest]

Thread overview: 289+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-17 16:09 [RFC] treewide: cleanup unreachable breaks trix
2020-10-17 16:09 ` [Intel-wired-lan] " trix
2020-10-17 16:09 ` trix
2020-10-17 16:09 ` trix
2020-10-17 16:09 ` trix
2020-10-17 16:09 ` trix
2020-10-17 16:09 ` trix
2020-10-17 16:09 ` trix-H+wXaHxf7aLQT0dZR+AlfA
2020-10-17 16:09 ` trix
2020-10-17 16:09 ` trix
2020-10-17 16:09 ` trix
2020-10-17 16:09 ` [Ocfs2-devel] " trix at redhat.com
2020-10-17 16:09 ` trix
2020-10-17 16:09 ` trix
2020-10-17 16:24 ` Martin Blumenstingl
2020-10-17 16:24   ` Martin Blumenstingl
2020-10-17 16:24   ` Martin Blumenstingl
2020-10-17 16:24 ` Joe Perches
2020-10-17 16:24   ` [Intel-wired-lan] " Joe Perches
2020-10-17 16:24   ` Joe Perches
2020-10-17 16:24   ` Joe Perches
2020-10-17 16:24   ` Joe Perches
2020-10-17 16:24   ` Joe Perches
2020-10-17 16:24   ` Joe Perches
2020-10-17 16:24   ` Joe Perches
2020-10-17 16:24   ` [Cocci] " Joe Perches
2020-10-17 16:24   ` Joe Perches
2020-10-17 16:24   ` Joe Perches
2020-10-17 16:24   ` Joe Perches
2020-10-17 16:24   ` Joe Perches
2020-10-17 16:24   ` [Ocfs2-devel] " Joe Perches
2020-10-17 16:24   ` Joe Perches
2020-10-17 16:24   ` Joe Perches
2020-10-17 18:21   ` [Cocci] " Julia Lawall
2020-10-17 18:21     ` [Intel-wired-lan] " Julia Lawall
2020-10-17 18:21     ` Julia Lawall
2020-10-17 18:21     ` Julia Lawall
2020-10-17 18:21     ` Julia Lawall
2020-10-17 18:21     ` Julia Lawall
2020-10-17 18:21     ` Julia Lawall
2020-10-17 18:21     ` Julia Lawall
2020-10-17 18:21     ` Julia Lawall
2020-10-17 18:21     ` Julia Lawall
2020-10-17 18:21     ` Julia Lawall
2020-10-17 18:21     ` Julia Lawall
2020-10-17 18:21     ` [Ocfs2-devel] " Julia Lawall
2020-10-17 18:21     ` Julia Lawall
2020-10-17 18:21     ` Julia Lawall
2020-10-17 19:00     ` Joe Perches
2020-10-17 19:00       ` [Intel-wired-lan] " Joe Perches
2020-10-17 19:00       ` Joe Perches
2020-10-17 19:00       ` Joe Perches
2020-10-17 19:00       ` Joe Perches
2020-10-17 19:00       ` Joe Perches
2020-10-17 19:00       ` Joe Perches
2020-10-17 19:00       ` Joe Perches
2020-10-17 19:00       ` Joe Perches
2020-10-17 19:00       ` Joe Perches
2020-10-17 19:00       ` Joe Perches
2020-10-17 19:00       ` Joe Perches
2020-10-17 19:00       ` Joe Perches
2020-10-17 19:00       ` [Ocfs2-devel] " Joe Perches
2020-10-17 19:00       ` Joe Perches
2020-10-17 19:00       ` Joe Perches
2020-10-18 19:49     ` [PATCH] checkpatch: Allow --fix removal of unnecessary break statements Joe Perches
2020-10-18 19:49       ` [Cocci] " Joe Perches
2020-10-18 20:07       ` Tom Rix
2020-10-18 20:07         ` [Cocci] " Tom Rix
2020-10-18 20:19         ` Joe Perches
2020-10-18 20:19           ` [Cocci] " Joe Perches
2020-10-19 12:55           ` Tom Rix
2020-10-19 12:55             ` [Cocci] " Tom Rix
2020-10-19 15:16             ` Joe Perches
2020-10-19 15:16               ` [Cocci] " Joe Perches
2020-10-19 15:36     ` [PATCH V2] " Joe Perches
2020-10-19 15:36       ` [Cocci] " Joe Perches
2020-10-17 21:01 ` [RFC] treewide: cleanup unreachable breaks Dan Williams
2020-10-17 21:01   ` [Intel-wired-lan] " Dan Williams
2020-10-17 21:01   ` Dan Williams
2020-10-17 21:01   ` Dan Williams
2020-10-17 21:01   ` Dan Williams
2020-10-17 21:01   ` Dan Williams
2020-10-17 21:01   ` Dan Williams
2020-10-17 21:01   ` Dan Williams
2020-10-17 21:01   ` Dan Williams
2020-10-17 21:01   ` Dan Williams
2020-10-17 21:01   ` Dan Williams
2020-10-17 21:01   ` Dan Williams
2020-10-17 21:01   ` Dan Williams
2020-10-17 21:01   ` [Ocfs2-devel] " Dan Williams
2020-10-17 21:01   ` Dan Williams
2020-10-17 21:01   ` Dan Williams
2020-10-18  5:43 ` Greg KH
2020-10-18  5:43   ` [Intel-wired-lan] " Greg KH
2020-10-18  5:43   ` Greg KH
2020-10-18  5:43   ` Greg KH
2020-10-18  5:43   ` Greg KH
2020-10-18  5:43   ` Greg KH
2020-10-18  5:43   ` Greg KH
2020-10-18  5:43   ` Greg KH
2020-10-18  5:43   ` Greg KH
2020-10-18  5:43   ` Greg KH
2020-10-18  5:43   ` Greg KH
2020-10-18  5:43   ` Greg KH
2020-10-18  5:43   ` [Ocfs2-devel] " Greg KH
2020-10-18  5:43   ` Greg KH
2020-10-18  5:43   ` Greg KH
2020-10-18 14:04   ` Tom Rix
2020-10-18 14:04     ` [Intel-wired-lan] " Tom Rix
2020-10-18 14:04     ` Tom Rix
2020-10-18 14:04     ` Tom Rix
2020-10-18 14:04     ` Tom Rix
2020-10-18 14:04     ` Tom Rix
2020-10-18 14:04     ` Tom Rix
2020-10-18 14:04     ` Tom Rix
2020-10-18 14:04     ` Tom Rix
2020-10-18 14:04     ` Tom Rix
2020-10-18 14:04     ` Tom Rix
2020-10-18 14:04     ` [Ocfs2-devel] " Tom Rix
2020-10-18 14:04     ` Tom Rix
2020-10-18 14:04     ` Tom Rix
2020-10-19 19:42   ` Nick Desaulniers
2020-10-19 19:42     ` [Intel-wired-lan] " Nick Desaulniers
2020-10-19 19:42     ` Nick Desaulniers
2020-10-19 19:42     ` Nick Desaulniers
2020-10-19 19:42     ` Nick Desaulniers
2020-10-19 19:42     ` Nick Desaulniers
2020-10-19 19:42     ` Nick Desaulniers
2020-10-19 19:42     ` Nick Desaulniers via Virtualization
2020-10-19 19:42     ` Nick Desaulniers
2020-10-19 19:42     ` Nick Desaulniers
2020-10-19 19:42     ` Nick Desaulniers
2020-10-19 19:42     ` Nick Desaulniers
2020-10-19 19:42     ` [Ocfs2-devel] " Nick Desaulniers
2020-10-19 19:42     ` Nick Desaulniers
2020-10-19 19:42     ` Nick Desaulniers
2020-10-19 23:05     ` Jason Gunthorpe
2020-10-19 23:05       ` [Intel-wired-lan] " Jason Gunthorpe
2020-10-19 23:05       ` Jason Gunthorpe
2020-10-19 23:05       ` Jason Gunthorpe
2020-10-19 23:05       ` Jason Gunthorpe
2020-10-19 23:05       ` Jason Gunthorpe
2020-10-19 23:05       ` Jason Gunthorpe
2020-10-19 23:05       ` Jason Gunthorpe
2020-10-19 23:05       ` Jason Gunthorpe
2020-10-19 23:05       ` Jason Gunthorpe
2020-10-19 23:05       ` Jason Gunthorpe
2020-10-19 23:05       ` Jason Gunthorpe
2020-10-19 23:05       ` [Ocfs2-devel] " Jason Gunthorpe
2020-10-20 14:09       ` Tom Rix
2020-10-20 14:09         ` [Intel-wired-lan] " Tom Rix
2020-10-20 14:09         ` Tom Rix
2020-10-20 14:09         ` Tom Rix
2020-10-20 14:09         ` Tom Rix
2020-10-20 14:09         ` Tom Rix
2020-10-20 14:09         ` Tom Rix
2020-10-20 14:09         ` Tom Rix
2020-10-20 14:09         ` Tom Rix
2020-10-20 14:09         ` Tom Rix
2020-10-20 14:09         ` Tom Rix
2020-10-20 14:09         ` [Ocfs2-devel] " Tom Rix
2020-10-20 14:09         ` Tom Rix
2020-10-20  8:47     ` [Ocfs2-devel] " John Haxby
2020-10-20  8:47       ` [Intel-wired-lan] " John Haxby
2020-10-20  8:47       ` John Haxby
2020-10-20  8:47       ` John Haxby
2020-10-20  8:47       ` John Haxby
2020-10-20  8:47       ` John Haxby
2020-10-20  8:47       ` John Haxby
2020-10-20  8:47       ` John Haxby
2020-10-20  8:47       ` John Haxby
2020-10-20  8:47       ` John Haxby
2020-10-20  8:47       ` John Haxby
2020-10-20  8:47       ` John Haxby
2020-10-20  8:47       ` John Haxby
2020-10-20 13:55     ` Tom Rix
2020-10-20 13:55       ` [Intel-wired-lan] " Tom Rix
2020-10-20 13:55       ` Tom Rix
2020-10-20 13:55       ` Tom Rix
2020-10-20 13:55       ` Tom Rix
2020-10-20 13:55       ` Tom Rix
2020-10-20 13:55       ` Tom Rix
2020-10-20 13:55       ` Tom Rix
2020-10-20 13:55       ` Tom Rix
2020-10-20 13:55       ` Tom Rix
2020-10-20 13:55       ` Tom Rix
2020-10-20 13:55       ` [Ocfs2-devel] " Tom Rix
2020-10-20 13:55       ` Tom Rix
2020-10-20 18:42     ` Joe Perches [this message]
2020-10-20 18:42       ` [Intel-wired-lan] " Joe Perches
2020-10-20 18:42       ` Joe Perches
2020-10-20 18:42       ` Joe Perches
2020-10-20 18:42       ` Joe Perches
2020-10-20 18:42       ` Joe Perches
2020-10-20 18:42       ` Joe Perches
2020-10-20 18:42       ` Joe Perches
2020-10-20 18:42       ` Joe Perches
2020-10-20 18:42       ` Joe Perches
2020-10-20 18:42       ` Joe Perches
2020-10-20 18:42       ` Joe Perches
2020-10-20 18:42       ` [Ocfs2-devel] " Joe Perches
2020-10-20 18:42       ` Joe Perches
2020-10-20 18:51       ` Nick Desaulniers
2020-10-20 18:54         ` Joe Perches
2020-10-18  9:29 ` Hans de Goede
2020-10-18  9:29   ` [Intel-wired-lan] " Hans de Goede
2020-10-18  9:29   ` Hans de Goede
2020-10-18  9:29   ` Hans de Goede
2020-10-18  9:29   ` Hans de Goede
2020-10-18  9:29   ` Hans de Goede
2020-10-18  9:29   ` Hans de Goede
2020-10-18  9:29   ` Hans de Goede
2020-10-18  9:29   ` Hans de Goede
2020-10-18  9:29   ` Hans de Goede
2020-10-18  9:29   ` Hans de Goede
2020-10-18  9:29   ` Hans de Goede
2020-10-18  9:29   ` [Ocfs2-devel] " Hans de Goede
2020-10-18  9:29   ` Hans de Goede
2020-10-18  9:29   ` Hans de Goede
2020-10-18 18:59 ` [Ocfs2-devel] " Matthew Wilcox
2020-10-18 18:59   ` [Intel-wired-lan] " Matthew Wilcox
2020-10-18 18:59   ` Matthew Wilcox
2020-10-18 18:59   ` Matthew Wilcox
2020-10-18 18:59   ` Matthew Wilcox
2020-10-18 18:59   ` Matthew Wilcox
2020-10-18 18:59   ` Matthew Wilcox
2020-10-18 18:59   ` Matthew Wilcox
2020-10-18 18:59   ` Matthew Wilcox
2020-10-18 18:59   ` Matthew Wilcox
2020-10-18 18:59   ` Matthew Wilcox
2020-10-18 18:59   ` Matthew Wilcox
2020-10-18 18:59   ` Matthew Wilcox
2020-10-18 18:59   ` Matthew Wilcox
2020-10-18 19:06   ` Joe Perches
2020-10-18 19:06     ` [Intel-wired-lan] " Joe Perches
2020-10-18 19:06     ` Joe Perches
2020-10-18 19:06     ` Joe Perches
2020-10-18 19:06     ` Joe Perches
2020-10-18 19:06     ` Joe Perches
2020-10-18 19:06     ` Joe Perches
2020-10-18 19:06     ` Joe Perches
2020-10-18 19:06     ` Joe Perches
2020-10-18 19:06     ` Joe Perches
2020-10-18 19:06     ` Joe Perches
2020-10-18 19:06     ` Joe Perches
2020-10-18 19:06     ` Joe Perches
2020-10-18 19:06     ` Joe Perches
2020-10-18 19:06     ` Joe Perches
2020-10-18 19:13   ` James Bottomley
2020-10-18 19:13     ` [Intel-wired-lan] " James Bottomley
2020-10-18 19:13     ` James Bottomley
2020-10-18 19:13     ` James Bottomley
2020-10-18 19:13     ` James Bottomley
2020-10-18 19:13     ` James Bottomley
2020-10-18 19:13     ` James Bottomley
2020-10-18 19:13     ` James Bottomley
2020-10-18 19:13     ` James Bottomley
2020-10-18 19:13     ` James Bottomley
2020-10-18 19:13     ` James Bottomley
2020-10-18 19:13     ` James Bottomley
2020-10-18 19:13     ` James Bottomley
2020-10-18 19:13     ` James Bottomley
2020-10-18 19:16     ` Matthew Wilcox
2020-10-18 19:16       ` [Intel-wired-lan] " Matthew Wilcox
2020-10-18 19:16       ` Matthew Wilcox
2020-10-18 19:16       ` Matthew Wilcox
2020-10-18 19:16       ` Matthew Wilcox
2020-10-18 19:16       ` Matthew Wilcox
2020-10-18 19:16       ` Matthew Wilcox
2020-10-18 19:16       ` Matthew Wilcox
2020-10-18 19:16       ` Matthew Wilcox
2020-10-18 19:16       ` Matthew Wilcox
2020-10-18 19:16       ` Matthew Wilcox
2020-10-18 19:16       ` Matthew Wilcox
2020-10-18 19:16       ` Matthew Wilcox
2020-10-18 19:17       ` James Bottomley
2020-10-18 19:17         ` [Intel-wired-lan] " James Bottomley
2020-10-18 19:17         ` James Bottomley
2020-10-18 19:17         ` James Bottomley
2020-10-18 19:17         ` James Bottomley
2020-10-18 19:17         ` James Bottomley
2020-10-18 19:17         ` James Bottomley
2020-10-18 19:17         ` James Bottomley
2020-10-18 19:17         ` James Bottomley
2020-10-18 19:17         ` James Bottomley
2020-10-18 19:17         ` James Bottomley
2020-10-18 19:17         ` James Bottomley
2020-10-18 19:17         ` James Bottomley
2020-10-18 19:17         ` James Bottomley

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=3bc5c2e3b3edc22a4d167ec807ecdaaf8dcda76d.camel@perches.com \
    --to=joe@perches.com \
    --cc=MPT-FusionLinux.pdl@broadcom.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=ath10k@lists.infradead.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=industrypack-devel@lists.sourceforge.net \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-amlogic@lists.infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-can@vger.kernel.org \
    --cc=linux-edac@vger.kernel.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-power@fi.rohmeurope.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=netdev@vger.kernel.org \
    --cc=nouveau@lists.freedesktop.org \
    --cc=openipmi-developer@lists.sourceforge.net \
    --cc=spice-devel@lists.freedesktop.org \
    --cc=trix@redhat.com \
    --cc=virtualization@lists.linux-foundation.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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.