[PATCH 0/5] -Wmaybe-uninitialized bug fixes for linux-next

[PATCH 0/5] -Wmaybe-uninitialized bug fixes for linux-next

[Arnd Bergmann]

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

[PATCH 2/5] video: ARM CLCD: fix endpoint lookup logic

[Arnd Bergmann]

The addition of the Nomadik support in this driver introduced
a bug in clcdfb_of_init_display(), which now calls init_panel
with an uninitialized 'endpoint' pointer, as "gcc -Wmaybe-uninitialized"
warns:

drivers/video/fbdev/amba-clcd.c: In function 'clcdfb_of_init_display':
drivers/video/fbdev/amba-clcd.c:785:5: error: 'endpoint' may be used uninitialized in this function [-Werror=maybe-uninitialized]

This reverts the broken part of the function to what it was before
the patch, which is the best guess I have to what it should be.
I assume this was left over from an attempted rework of the
code that was partially backed out.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 046ad6cdeb3f ("video: ARM CLCD: support Nomadik variant")
Cc: Linus Walleij <linus.walleij@linaro.org>
---
Cc: linux-fbdev@vger.kernel.org
Cc: Russell King <linux@armlinux.org.uk>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
 drivers/video/fbdev/amba-clcd.c | 9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/video/fbdev/amba-clcd.c b/drivers/video/fbdev/amba-clcd.c
index c342ff370108..ec2671d98abc 100644
--- a/drivers/video/fbdev/amba-clcd.c
+++ b/drivers/video/fbdev/amba-clcd.c
@@ -782,12 +782,9 @@ static int clcdfb_of_init_display(struct clcd_fb *fb)
 	/*
 	 * Fetch the panel endpoint.
 	 */
-	if (!endpoint) {
-		endpoint = of_graph_get_next_endpoint(fb->dev->dev.of_node,
-						      NULL);
-		if (!endpoint)
-			return -ENODEV;
-	}
+	endpoint = of_graph_get_next_endpoint(fb->dev->dev.of_node, NULL);
+	if (!endpoint)
+		return -ENODEV;
 
 	if (fb->vendor->init_panel) {
 		err = fb->vendor->init_panel(fb, endpoint);
-- 
2.9.0

Re: [PATCH 2/5] video: ARM CLCD: fix endpoint lookup logic

[Linus Walleij]

On Fri, Aug 26, 2016 at 5:25 PM, Arnd Bergmann <arnd@arndb.de> wrote:

[I don't see why Torvalds was CC'ed on this patch? Was there
some specific complaint from his side that I screw things up
or just the wrong Linus?]

> The addition of the Nomadik support in this driver introduced
> a bug in clcdfb_of_init_display(), which now calls init_panel
> with an uninitialized 'endpoint' pointer, as "gcc -Wmaybe-uninitialized"
> warns:
>
> drivers/video/fbdev/amba-clcd.c: In function 'clcdfb_of_init_display':
> drivers/video/fbdev/amba-clcd.c:785:5: error: 'endpoint' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>
> This reverts the broken part of the function to what it was before
> the patch, which is the best guess I have to what it should be.
> I assume this was left over from an attempted rework of the
> code that was partially backed out.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Fixes: 046ad6cdeb3f ("video: ARM CLCD: support Nomadik variant")
> Cc: Linus Walleij <linus.walleij@linaro.org>

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Tomi: I think this bug was also reported by Ian King, so suggest
adding his
Reported-by: Colin Ian King <colin.king@canonical.com>

When applying.

Yours,
Linus Walleij

Re: [PATCH 2/5] video: ARM CLCD: fix endpoint lookup logic

[Arnd Bergmann]

On Monday 29 August 2016, Linus Walleij wrote:
> On Fri, Aug 26, 2016 at 5:25 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> 
> [I don't see why Torvalds was CC'ed on this patch? Was there
> some specific complaint from his side that I screw things up
> or just the wrong Linus?]

It was intentional: as mentioned in the introductory mail, he did
the patch that prevented you from seeing the five warnings that I got
after reverting 6e8d666e9253.

	Arnd

Re: [PATCH 2/5] video: ARM CLCD: fix endpoint lookup logic

[Tomi Valkeinen]

[-- Attachment #1.1: Type: text/plain, Size: 1380 bytes --]


On 29/08/16 16:18, Linus Walleij wrote:
> On Fri, Aug 26, 2016 at 5:25 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> 
> [I don't see why Torvalds was CC'ed on this patch? Was there
> some specific complaint from his side that I screw things up
> or just the wrong Linus?]
> 
>> The addition of the Nomadik support in this driver introduced
>> a bug in clcdfb_of_init_display(), which now calls init_panel
>> with an uninitialized 'endpoint' pointer, as "gcc -Wmaybe-uninitialized"
>> warns:
>>
>> drivers/video/fbdev/amba-clcd.c: In function 'clcdfb_of_init_display':
>> drivers/video/fbdev/amba-clcd.c:785:5: error: 'endpoint' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>>
>> This reverts the broken part of the function to what it was before
>> the patch, which is the best guess I have to what it should be.
>> I assume this was left over from an attempted rework of the
>> code that was partially backed out.
>>
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>> Fixes: 046ad6cdeb3f ("video: ARM CLCD: support Nomadik variant")
>> Cc: Linus Walleij <linus.walleij@linaro.org>
> 
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> 
> Tomi: I think this bug was also reported by Ian King, so suggest
> adding his
> Reported-by: Colin Ian King <colin.king@canonical.com>
> 

Thanks, queued for v4.9.

 Tomi


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]