From: Arnd Bergmann <arnd@arndb.de>
To: linux-kernel@vger.kernel.org
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Arnd Bergmann <arnd@arndb.de>,
Alexandre Courbot <gnurou@gmail.com>,
David Howells <dhowells@redhat.com>,
"David S. Miller" <davem@davemloft.net>,
Fushen Chen <fchen@apm.com>, Hadar Hen Zion <hadarh@mellanox.com>,
Iyappan Subramanian <isubramanian@apm.com>,
Jiri Pirko <jiri@mellanox.com>, Keyur Chudgar <kchudgar@apm.com>,
Linus Walleij <linus.walleij@linaro.org>,
Phil Reid <preid@electromag.com.au>,
Russell King <linux@armlinux.org.uk>,
Tomi Valkeinen <tomi.valkeinen@ti.com>,
linux-fbdev@vger.kernel.org, linux-gpio@vger.kernel.org,
netdev@vger.kernel.org
Subject: [PATCH 0/5] -Wmaybe-uninitialized bug fixes for linux-next
Date: Fri, 26 Aug 2016 15:25:41 +0000 [thread overview]
Message-ID: <20160826152546.604384-1-arnd@arndb.de> (raw)
In 6e8d666e9253 ("Disable "maybe-uninitialized" warning globally"),
Linus wrote:
Looking at the warnings produced, every single one I looked at was a
false positive, and the warnings are frequent enough (and big enough)
that they can easily hide real problems that you don't notice in
the noise generated by -Wmaybe-uninitialized.
Today, I tried reverting the patch on linux-next and built an ARM
allmodconfig kernel on ARM along with some randconfig kernels,
and got a handful of warnings, all of which appear to be reasonable
and point to actual mistakes in the code. The difference to what
Linus saw must be that previously the useful warnings were more
likely to get fixed before making it into the kernel, while now
we have to find them the hard way.
These five patches address all new warnings. In some cases this
may not be the correct fix, so please review carefully before applying,
or suggest a better fix. No need to keep them as a series, I
just group them here for the sake of discussion. Please pick up
whatever looks right to you.
Obviously, this kind of warnings always produces some false positives
(see https://gcc.gnu.org/wiki/Better_Uninitialized_Warnings), but I still
hope to get a better balance with enabling them sometimes where
people want them, as the current approach of always enabling them
for "make W=1" but never by default seems suboptimal: We had previously
identified a number of options (CONFIG_CC_OPTIMIZE_FOR_SIZE,
CONFIG_PROFILE_ALL_BRANCHES, CONFIG_UBSAN_ALIGNMENT, and
CONFIG_GCOV_PROFILE_ALL) that cause tons of false positives,
but without those options (and avoiding gcc-4.8 or lower),
we typically get mostly reports for actual bugs in my experience.
I can continue running the tests and send patches, but it feels
like a waste of time when they should have been found by the
original developers. Any other suggestions?
Arnd
Arnd Bergmann (5):
gpio: pca954x: fix undefined error code from remove
video: ARM CLCD: fix endpoint lookup logic
rxrpc: fix last_call processing
net_sched: fix use of uninitialized ethertype variable in cls_flower
net/xgene: fix error handling during reset
drivers/gpio/gpio-pca953x.c | 2 ++
drivers/net/ethernet/apm/xgene/xgene_enet_xgmac.c | 12 +++++++++---
drivers/video/fbdev/amba-clcd.c | 9 +++------
net/rxrpc/input.c | 8 ++++----
net/sched/cls_flower.c | 21 +++++++++++----------
5 files changed, 29 insertions(+), 23 deletions(-)
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: David Howells <dhowells@redhat.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Fushen Chen <fchen@apm.com>
Cc: Hadar Hen Zion <hadarh@mellanox.com>
Cc: Iyappan Subramanian <isubramanian@apm.com>
Cc: Jiri Pirko <jiri@mellanox.com>
Cc: Keyur Chudgar <kchudgar@apm.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Phil Reid <preid@electromag.com.au>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-gpio@vger.kernel.org
Cc: netdev@vger.kernel.org
--
2.9.0
next reply other threads:[~2016-08-26 15:25 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-26 15:25 Arnd Bergmann [this message]
2016-08-26 15:25 ` [PATCH 2/5] video: ARM CLCD: fix endpoint lookup logic Arnd Bergmann
2016-08-29 13:18 ` Linus Walleij
2016-08-29 13:41 ` Arnd Bergmann
2016-08-30 8:35 ` Tomi Valkeinen
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=20160826152546.604384-1-arnd@arndb.de \
--to=arnd@arndb.de \
--cc=davem@davemloft.net \
--cc=dhowells@redhat.com \
--cc=fchen@apm.com \
--cc=gnurou@gmail.com \
--cc=hadarh@mellanox.com \
--cc=isubramanian@apm.com \
--cc=jiri@mellanox.com \
--cc=kchudgar@apm.com \
--cc=linus.walleij@linaro.org \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=netdev@vger.kernel.org \
--cc=preid@electromag.com.au \
--cc=tomi.valkeinen@ti.com \
--cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox