Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1502518 > unrolled thread

[PATCH 00/28] Reenable maybe-uninitialized warnings

Back to article view | Back to linux.kernel

Contents

  [PATCH 00/28] Reenable maybe-uninitialized warnings Arnd Bergmann <arnd@arndb.de> - 2016-10-18 00:10 +0200
    [PATCH 08/28] staging: lustre: restore initialization of return code Arnd Bergmann <arnd@arndb.de> - 2016-10-18 00:20 +0200
      Re: [lustre-devel] [PATCH 08/28] staging: lustre: restore  initialization of return code Linus Torvalds <torvalds@linux-foundation.org> - 2016-10-18 00:40 +0200
        Re: [lustre-devel] [PATCH 08/28] staging: lustre: restore initialization of return code Arnd Bergmann <arnd@arndb.de> - 2016-10-18 01:10 +0200
      Re: [lustre-devel] [PATCH 08/28] staging: lustre: restore initialization of return code Arnd Bergmann <arnd@arndb.de> - 2016-10-18 00:40 +0200
      [PATCH 08/28 v2] staging: lustre: restore initialization of return code Arnd Bergmann <arnd@arndb.de> - 2016-10-18 00:50 +0200
    [PATCH 11/28] block: rdb: false-postive gcc-4.9 -Wmaybe-uninitialized Arnd Bergmann <arnd@arndb.de> - 2016-10-18 00:20 +0200
      Re: [PATCH 11/28] block: rdb: false-postive gcc-4.9 -Wmaybe-uninitialized Ilya Dryomov <idryomov@gmail.com> - 2016-10-18 12:00 +0200
        Re: [PATCH 11/28] block: rdb: false-postive gcc-4.9 -Wmaybe-uninitialized Arnd Bergmann <arnd@arndb.de> - 2016-10-18 12:10 +0200
    [PATCH 21/28] net/hyperv: avoid uninitialized variable Arnd Bergmann <arnd@arndb.de> - 2016-10-18 00:20 +0200
      Re: [PATCH 21/28] net/hyperv: avoid uninitialized variable David Miller <davem@davemloft.net> - 2016-10-18 20:30 +0200
    [PATCH 15/28] crypto: aesni: avoid -Wmaybe-uninitialized warning Arnd Bergmann <arnd@arndb.de> - 2016-10-18 00:20 +0200
    [PATCH 19/28] brcmfmac: avoid maybe-uninitialized warning in brcmf_cfg80211_start_ap Arnd Bergmann <arnd@arndb.de> - 2016-10-18 00:20 +0200
      Re: [PATCH 19/28] brcmfmac: avoid maybe-uninitialized warning in brcmf_cfg80211_start_ap Kalle Valo <kvalo@codeaurora.org> - 2016-10-26 09:00 +0200
        Re: [PATCH 19/28] brcmfmac: avoid maybe-uninitialized warning in brcmf_cfg80211_start_ap Arnd Bergmann <arnd@arndb.de> - 2016-10-26 12:00 +0200
          Re: [PATCH 19/28] brcmfmac: avoid maybe-uninitialized warning in brcmf_cfg80211_start_ap Kalle Valo <kvalo@codeaurora.org> - 2016-10-26 13:20 +0200
    [PATCH 13/28] [media] dib0700: fix uninitialized data on 'repeat' event Arnd Bergmann <arnd@arndb.de> - 2016-10-18 00:20 +0200
    [PATCH 18/28] drm: avoid uninitialized timestamp use in wait_vblank Arnd Bergmann <arnd@arndb.de> - 2016-10-18 00:20 +0200
      Re: [PATCH 18/28] drm: avoid uninitialized timestamp use in  wait_vblank Mario Kleiner <mario.kleiner.de@gmail.com> - 2016-10-18 01:50 +0200
        Re: [PATCH 18/28] drm: avoid uninitialized timestamp use in  wait_vblank Daniel Vetter <daniel@ffwll.ch> - 2016-10-18 09:50 +0200
    [PATCH 09/28] staging: lustre: remove broken dead code in cfs_cpt_table_create_pattern Arnd Bergmann <arnd@arndb.de> - 2016-10-18 00:20 +0200
    [PATCH 16/28] pcmcia: fix return value of soc_pcmcia_regulator_set Arnd Bergmann <arnd@arndb.de> - 2016-10-18 00:20 +0200
      Re: [PATCH 16/28] pcmcia: fix return value of  soc_pcmcia_regulator_set Russell King - ARM Linux <linux@armlinux.org.uk> - 2016-10-18 11:50 +0200
    [PATCH 20/28] net: bcm63xx: avoid referencing uninitialized variable Arnd Bergmann <arnd@arndb.de> - 2016-10-18 00:20 +0200
      Re: [PATCH 20/28] net: bcm63xx: avoid referencing uninitialized  variable David Miller <davem@davemloft.net> - 2016-10-18 20:30 +0200
    [PATCH 12/28] [media] rc: print correct variable for z8f0811 Arnd Bergmann <arnd@arndb.de> - 2016-10-18 00:20 +0200
    [PATCH 17/28] spi: fsl-espi: avoid processing uninitalized data on error Arnd Bergmann <arnd@arndb.de> - 2016-10-18 00:20 +0200
      Re: [PATCH 17/28] spi: fsl-espi: avoid processing uninitalized data  on error Heiner Kallweit <hkallweit1@gmail.com> - 2016-10-24 20:40 +0200
        Re: [PATCH 17/28] spi: fsl-espi: avoid processing uninitalized data  on error Mark Brown <broonie@kernel.org> - 2016-10-24 20:50 +0200
          Re: [PATCH 17/28] spi: fsl-espi: avoid processing uninitalized data on error Arnd Bergmann <arnd@arndb.de> - 2016-10-24 22:40 +0200
            Re: [PATCH 17/28] spi: fsl-espi: avoid processing uninitalized data  on error Mark Brown <broonie@kernel.org> - 2016-10-25 21:20 +0200
              Re: [PATCH 17/28] spi: fsl-espi: avoid processing uninitalized data on error Arnd Bergmann <arnd@arndb.de> - 2016-10-25 23:00 +0200
      Re: [PATCH 17/28] spi: fsl-espi: avoid processing uninitalized data  on error Mark Brown <broonie@kernel.org> - 2016-10-24 21:00 +0200
      Applied "spi: fsl-espi: avoid processing uninitalized data on error" to the spi tree Mark Brown <broonie@kernel.org> - 2016-10-26 12:30 +0200
        Merge problem: Re: Applied "spi: fsl-espi: avoid processing  uninitalized data on error" to the spi tree Heiner Kallweit <hkallweit1@gmail.com> - 2016-10-26 20:20 +0200
          Re: Merge problem: Re: Applied "spi: fsl-espi: avoid processing  uninitalized data on error" to the spi tree Mark Brown <broonie@kernel.org> - 2016-10-27 00:00 +0200
    [PATCH 10/28] UBI: fix uninitialized access of vid_hdr pointer Arnd Bergmann <arnd@arndb.de> - 2016-10-18 00:20 +0200
      Re: [PATCH 10/28] UBI: fix uninitialized access of vid_hdr pointer Boris Brezillon <boris.brezillon@free-electrons.com> - 2016-10-18 07:20 +0200
    [PATCH 14/28] iio: accel: sca3000_core: avoid potentially uninitialized variable Arnd Bergmann <arnd@arndb.de> - 2016-10-18 00:20 +0200
      Re: [PATCH 14/28] iio: accel: sca3000_core: avoid potentially  uninitialized variable Jonathan Cameron <jic23@kernel.org> - 2016-10-23 23:30 +0200
    [PATCH 24/28] x86: math-emu: possible uninitialized variable use Arnd Bergmann <arnd@arndb.de> - 2016-10-18 00:30 +0200
    [PATCH 22/28] x86: apm: avoid uninitialized data Arnd Bergmann <arnd@arndb.de> - 2016-10-18 00:30 +0200
      Re: [PATCH 22/28] x86: apm: avoid uninitialized data Jiri Kosina <jikos@kernel.org> - 2016-10-18 15:10 +0200
      Re: [PATCH 22/28] x86: apm: avoid uninitialized data "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-10-18 23:40 +0200
    [PATCH 27/28] rocker: fix maybe-uninitialized warning Arnd Bergmann <arnd@arndb.de> - 2016-10-18 00:30 +0200
      Re: [PATCH 27/28] rocker: fix maybe-uninitialized warning David Miller <davem@davemloft.net> - 2016-10-18 20:30 +0200
    [PATCH 26/28] nios2: fix timer initcall return value Arnd Bergmann <arnd@arndb.de> - 2016-10-18 00:30 +0200
      Re: [PATCH 26/28] nios2: fix timer initcall return value Ley Foon Tan <lftan@altera.com> - 2016-10-24 03:00 +0200
    [PATCH 25/28] s390: pci: don't print uninitialized data for debugging Arnd Bergmann <arnd@arndb.de> - 2016-10-18 00:30 +0200
      Re: [PATCH 25/28] s390: pci: don't print uninitialized data for  debugging Martin Schwidefsky <schwidefsky@de.ibm.com> - 2016-10-18 09:00 +0200
        Re: [PATCH 25/28] s390: pci: don't print uninitialized data for  debugging Sebastian Ott <sebott@linux.vnet.ibm.com> - 2016-10-18 11:00 +0200
    [PATCH 23/28] x86: mark target address as output in 'insb' asm Arnd Bergmann <arnd@arndb.de> - 2016-10-18 00:30 +0200
    [PATCH 28/28] Kbuild: bring back -Wmaybe-uninitialized warning Arnd Bergmann <arnd@arndb.de> - 2016-10-18 00:30 +0200
    Re: [PATCH 00/28] Reenable maybe-uninitialized warnings Christoph Hellwig <hch@infradead.org> - 2016-10-18 07:10 +0200

Page 3 of 3 — ← Prev page 1 2 [3]

#1502539 — [PATCH 24/28] x86: math-emu: possible uninitialized variable use

When building the kernel with "make EXTRA_CFLAGS=...", this overrides
the "PARANOID" preprocessor macro defined in arch/x86/math-emu/Makefile,
and we run into a build warning:

arch/x86/math-emu/reg_compare.c: In function ‘compare_i_st_st’:
arch/x86/math-emu/reg_compare.c:254:6: error: ‘f’ may be used uninitialized in this function [-Werror=maybe-uninitialized]

This fixes the implementation to work correctly even without the PARANOID
flag, and also fixes the Makefile to not use the EXTRA_CFLAGS variable
but instead use the ccflags-y variable in the Makefile that is meant
for this purpose.

Cc: x86@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/x86/math-emu/Makefile      |  4 ++--
 arch/x86/math-emu/reg_compare.c | 16 ++++++++--------
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/arch/x86/math-emu/Makefile b/arch/x86/math-emu/Makefile
index 9b0c63b..1b2dac1 100644
--- a/arch/x86/math-emu/Makefile
+++ b/arch/x86/math-emu/Makefile
@@ -5,8 +5,8 @@
 #DEBUG	= -DDEBUGGING
 DEBUG	=
 PARANOID = -DPARANOID
-EXTRA_CFLAGS	:= $(PARANOID) $(DEBUG) -fno-builtin $(MATH_EMULATION)
-EXTRA_AFLAGS	:= $(PARANOID)
+ccflags-y += $(PARANOID) $(DEBUG) -fno-builtin $(MATH_EMULATION)
+asflags-y += $(PARANOID)
 
 # From 'C' language sources:
 C_OBJS =fpu_entry.o errors.o \
diff --git a/arch/x86/math-emu/reg_compare.c b/arch/x86/math-emu/reg_compare.c
index b77360f..19b33b50 100644
--- a/arch/x86/math-emu/reg_compare.c
+++ b/arch/x86/math-emu/reg_compare.c
@@ -168,7 +168,7 @@ static int compare(FPU_REG const *b, int tagb)
 /* This function requires that st(0) is not empty */
 int FPU_compare_st_data(FPU_REG const *loaded_data, u_char loaded_tag)
 {
-	int f = 0, c;
+	int f, c;
 
 	c = compare(loaded_data, loaded_tag);
 
@@ -189,12 +189,12 @@ int FPU_compare_st_data(FPU_REG const *loaded_data, u_char loaded_tag)
 		case COMP_No_Comp:
 			f = SW_C3 | SW_C2 | SW_C0;
 			break;
-#ifdef PARANOID
 		default:
+#ifdef PARANOID
 			EXCEPTION(EX_INTERNAL | 0x121);
+#endif /* PARANOID */
 			f = SW_C3 | SW_C2 | SW_C0;
 			break;
-#endif /* PARANOID */
 		}
 	setcc(f);
 	if (c & COMP_Denormal) {
@@ -205,7 +205,7 @@ int FPU_compare_st_data(FPU_REG const *loaded_data, u_char loaded_tag)
 
 static int compare_st_st(int nr)
 {
-	int f = 0, c;
+	int f, c;
 	FPU_REG *st_ptr;
 
 	if (!NOT_EMPTY(0) || !NOT_EMPTY(nr)) {
@@ -235,12 +235,12 @@ static int compare_st_st(int nr)
 		case COMP_No_Comp:
 			f = SW_C3 | SW_C2 | SW_C0;
 			break;
-#ifdef PARANOID
 		default:
+#ifdef PARANOID
 			EXCEPTION(EX_INTERNAL | 0x122);
+#endif /* PARANOID */
 			f = SW_C3 | SW_C2 | SW_C0;
 			break;
-#endif /* PARANOID */
 		}
 	setcc(f);
 	if (c & COMP_Denormal) {
@@ -283,12 +283,12 @@ static int compare_i_st_st(int nr)
 	case COMP_No_Comp:
 		f = X86_EFLAGS_ZF | X86_EFLAGS_PF | X86_EFLAGS_CF;
 		break;
-#ifdef PARANOID
 	default:
+#ifdef PARANOID
 		EXCEPTION(EX_INTERNAL | 0x122);
+#endif /* PARANOID */
 		f = 0;
 		break;
-#endif /* PARANOID */
 	}
 	FPU_EFLAGS = (FPU_EFLAGS & ~(X86_EFLAGS_ZF | X86_EFLAGS_PF | X86_EFLAGS_CF)) | f;
 	if (c & COMP_Denormal) {
-- 
2.9.0

[toc] | [prev] | [next] | [standalone]

#1502544 — [PATCH 22/28] x86: apm: avoid uninitialized data

apm_bios_call() can fail, and return a status in its argument
structure. If that status however is zero during a call from
apm_get_power_status(), we end up using data that may have
never been set, as reported by "gcc -Wmaybe-uninitialized":

arch/x86/kernel/apm_32.c: In function ‘apm’:
arch/x86/kernel/apm_32.c:1729:17: error: ‘bx’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
arch/x86/kernel/apm_32.c:1835:5: error: ‘cx’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
arch/x86/kernel/apm_32.c:1730:17: note: ‘cx’ was declared here
arch/x86/kernel/apm_32.c:1842:27: error: ‘dx’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
arch/x86/kernel/apm_32.c:1731:17: note: ‘dx’ was declared here

This changes the function to return "APM_NO_ERROR" here, which
makes the code more robust to broken BIOS versions, and avoids
the warning.

Cc: x86@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/x86/kernel/apm_32.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/apm_32.c b/arch/x86/kernel/apm_32.c
index c7364bd..51287cd 100644
--- a/arch/x86/kernel/apm_32.c
+++ b/arch/x86/kernel/apm_32.c
@@ -1042,8 +1042,11 @@ static int apm_get_power_status(u_short *status, u_short *bat, u_short *life)
 
 	if (apm_info.get_power_status_broken)
 		return APM_32_UNSUPPORTED;
-	if (apm_bios_call(&call))
+	if (apm_bios_call(&call)) {
+		if (!call.err)
+			return APM_NO_ERROR;
 		return call.err;
+	}
 	*status = call.ebx;
 	*bat = call.ecx;
 	if (apm_info.get_power_status_swabinminutes) {
-- 
2.9.0

[toc] | [prev] | [next] | [standalone]

#1502972 — Re: [PATCH 22/28] x86: apm: avoid uninitialized data

On Tue, 18 Oct 2016, Arnd Bergmann wrote:

> apm_bios_call() can fail, and return a status in its argument
> structure. If that status however is zero during a call from
> apm_get_power_status(), we end up using data that may have
> never been set, as reported by "gcc -Wmaybe-uninitialized":
> 
> arch/x86/kernel/apm_32.c: In function ‘apm’:
> arch/x86/kernel/apm_32.c:1729:17: error: ‘bx’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
> arch/x86/kernel/apm_32.c:1835:5: error: ‘cx’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
> arch/x86/kernel/apm_32.c:1730:17: note: ‘cx’ was declared here
> arch/x86/kernel/apm_32.c:1842:27: error: ‘dx’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
> arch/x86/kernel/apm_32.c:1731:17: note: ‘dx’ was declared here
> 
> This changes the function to return "APM_NO_ERROR" here, which
> makes the code more robust to broken BIOS versions, and avoids
> the warning.
> 
> Cc: x86@kernel.org
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Makes sense.

Reviewed-by: Jiri Kosina <jkosina@suse.cz>

Thanks,

-- 
Jiri Kosina
SUSE Labs

[toc] | [prev] | [next] | [standalone]

#1503383 — Re: [PATCH 22/28] x86: apm: avoid uninitialized data

On Tue, Oct 18, 2016 at 12:16:10AM +0200, Arnd Bergmann wrote:
> apm_bios_call() can fail, and return a status in its argument
> structure. If that status however is zero during a call from
> apm_get_power_status(), we end up using data that may have
> never been set, as reported by "gcc -Wmaybe-uninitialized":

Userspace *may* already rely on this broken behavior for broken
BIOSes which may leave the return value as 0, ignoring that,
this change makes sense to me given that handling the error
would be better than relying any possible invalid data.

> arch/x86/kernel/apm_32.c: In function ‘apm’:
> arch/x86/kernel/apm_32.c:1729:17: error: ‘bx’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
> arch/x86/kernel/apm_32.c:1835:5: error: ‘cx’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
> arch/x86/kernel/apm_32.c:1730:17: note: ‘cx’ was declared here
> arch/x86/kernel/apm_32.c:1842:27: error: ‘dx’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
> arch/x86/kernel/apm_32.c:1731:17: note: ‘dx’ was declared here
> 
> This changes the function to return "APM_NO_ERROR" here, which
> makes the code more robust to broken BIOS versions, and avoids
> the warning.
> 
> Cc: x86@kernel.org
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Reviewed-by: Luis R. Rodriguez <mcgrof@kernel.org>

  Luis

> ---
>  arch/x86/kernel/apm_32.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/kernel/apm_32.c b/arch/x86/kernel/apm_32.c
> index c7364bd..51287cd 100644
> --- a/arch/x86/kernel/apm_32.c
> +++ b/arch/x86/kernel/apm_32.c
> @@ -1042,8 +1042,11 @@ static int apm_get_power_status(u_short *status, u_short *bat, u_short *life)
>  
>  	if (apm_info.get_power_status_broken)
>  		return APM_32_UNSUPPORTED;
> -	if (apm_bios_call(&call))
> +	if (apm_bios_call(&call)) {
> +		if (!call.err)
> +			return APM_NO_ERROR;
>  		return call.err;
> +	}
>  	*status = call.ebx;
>  	*bat = call.ecx;
>  	if (apm_info.get_power_status_swabinminutes) {
> -- 
> 2.9.0
> 
> 

-- 
Luis Rodriguez, SUSE LINUX GmbH
Maxfeldstrasse 5; D-90409 Nuernberg

[toc] | [prev] | [next] | [standalone]

#1502547 — [PATCH 27/28] rocker: fix maybe-uninitialized warning

In some rare configurations, we get a warning about the 'index' variable
being used without an initialization:

drivers/net/ethernet/rocker/rocker_ofdpa.c: In function ‘ofdpa_port_fib_ipv4.isra.16.constprop’:
drivers/net/ethernet/rocker/rocker_ofdpa.c:2425:92: warning: ‘index’ may be used uninitialized in this function [-Wmaybe-uninitialized]

This is a false positive, the logic is just a bit too complex for gcc
to follow here. Moving the intialization of 'index' a little further
down makes it clear to gcc that the function always returns an error
if it is not initialized.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/net/ethernet/rocker/rocker_ofdpa.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/rocker/rocker_ofdpa.c b/drivers/net/ethernet/rocker/rocker_ofdpa.c
index 431a608..4ca4613 100644
--- a/drivers/net/ethernet/rocker/rocker_ofdpa.c
+++ b/drivers/net/ethernet/rocker/rocker_ofdpa.c
@@ -1493,8 +1493,6 @@ static int ofdpa_port_ipv4_nh(struct ofdpa_port *ofdpa_port,
 	spin_lock_irqsave(&ofdpa->neigh_tbl_lock, lock_flags);
 
 	found = ofdpa_neigh_tbl_find(ofdpa, ip_addr);
-	if (found)
-		*index = found->index;
 
 	updating = found && adding;
 	removing = found && !adding;
@@ -1508,9 +1506,11 @@ static int ofdpa_port_ipv4_nh(struct ofdpa_port *ofdpa_port,
 		resolved = false;
 	} else if (removing) {
 		ofdpa_neigh_del(trans, found);
+		*index = found->index;
 	} else if (updating) {
 		ofdpa_neigh_update(found, trans, NULL, false);
 		resolved = !is_zero_ether_addr(found->eth_dst);
+		*index = found->index;
 	} else {
 		err = -ENOENT;
 	}
-- 
2.9.0

[toc] | [prev] | [next] | [standalone]

#1503283 — Re: [PATCH 27/28] rocker: fix maybe-uninitialized warning

From: Arnd Bergmann <arnd@arndb.de>
Date: Tue, 18 Oct 2016 00:16:15 +0200

> In some rare configurations, we get a warning about the 'index' variable
> being used without an initialization:
> 
> drivers/net/ethernet/rocker/rocker_ofdpa.c: In function ‘ofdpa_port_fib_ipv4.isra.16.constprop’:
> drivers/net/ethernet/rocker/rocker_ofdpa.c:2425:92: warning: ‘index’ may be used uninitialized in this function [-Wmaybe-uninitialized]
> 
> This is a false positive, the logic is just a bit too complex for gcc
> to follow here. Moving the intialization of 'index' a little further
> down makes it clear to gcc that the function always returns an error
> if it is not initialized.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Applied.

[toc] | [prev] | [next] | [standalone]

#1502549 — [PATCH 26/28] nios2: fix timer initcall return value

When called more than twice, the nios2_time_init() function
return an uninitialized value, as detected by gcc -Wmaybe-uninitialized

arch/nios2/kernel/time.c: warning: 'ret' may be used uninitialized in this function

This makes it return '0' here, matching the comment above the
function.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/nios2/kernel/time.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/nios2/kernel/time.c b/arch/nios2/kernel/time.c
index d9563dd..746bf5c 100644
--- a/arch/nios2/kernel/time.c
+++ b/arch/nios2/kernel/time.c
@@ -324,6 +324,7 @@ static int __init nios2_time_init(struct device_node *timer)
 		ret = nios2_clocksource_init(timer);
 		break;
 	default:
+		ret = 0;
 		break;
 	}
 
-- 
2.9.0

[toc] | [prev] | [next] | [standalone]

#1506814 — Re: [PATCH 26/28] nios2: fix timer initcall return value

On Tue, Oct 18, 2016 at 6:16 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> When called more than twice, the nios2_time_init() function
> return an uninitialized value, as detected by gcc -Wmaybe-uninitialized
>
> arch/nios2/kernel/time.c: warning: 'ret' may be used uninitialized in this function
>
> This makes it return '0' here, matching the comment above the
> function.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>  arch/nios2/kernel/time.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/arch/nios2/kernel/time.c b/arch/nios2/kernel/time.c
> index d9563dd..746bf5c 100644
> --- a/arch/nios2/kernel/time.c
> +++ b/arch/nios2/kernel/time.c
> @@ -324,6 +324,7 @@ static int __init nios2_time_init(struct device_node *timer)
>                 ret = nios2_clocksource_init(timer);
>                 break;
>         default:
> +               ret = 0;
>                 break;
>         }
Acked-by: Ley Foon Tan <lftan@altera.com>

[toc] | [prev] | [next] | [standalone]

#1502550 — [PATCH 25/28] s390: pci: don't print uninitialized data for debugging

gcc correctly warns about an incorrect use of the 'pa' variable
in case we pass an empty scatterlist to __s390_dma_map_sg:

arch/s390/pci/pci_dma.c: In function '__s390_dma_map_sg':
arch/s390/pci/pci_dma.c:309:13: warning: 'pa' may be used uninitialized in this function [-Wmaybe-uninitialized]

This adds a bogus initialization to the function to sanitize
the debug output.  I would have preferred a solution without
the initialization, but I only got the report from the
kbuild bot after turning on the warning again, and didn't
manage to reproduce it myself.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/s390/pci/pci_dma.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/s390/pci/pci_dma.c b/arch/s390/pci/pci_dma.c
index 7350c8b..6b2f72f 100644
--- a/arch/s390/pci/pci_dma.c
+++ b/arch/s390/pci/pci_dma.c
@@ -423,7 +423,7 @@ static int __s390_dma_map_sg(struct device *dev, struct scatterlist *sg,
 	dma_addr_t dma_addr_base, dma_addr;
 	int flags = ZPCI_PTE_VALID;
 	struct scatterlist *s;
-	unsigned long pa;
+	unsigned long pa = 0;
 	int ret;
 
 	size = PAGE_ALIGN(size);
-- 
2.9.0

[toc] | [prev] | [next] | [standalone]

#1502722 — Re: [PATCH 25/28] s390: pci: don't print uninitialized data for debugging

On Tue, 18 Oct 2016 00:16:13 +0200
Arnd Bergmann <arnd@arndb.de> wrote:

> gcc correctly warns about an incorrect use of the 'pa' variable
> in case we pass an empty scatterlist to __s390_dma_map_sg:
> 
> arch/s390/pci/pci_dma.c: In function '__s390_dma_map_sg':
> arch/s390/pci/pci_dma.c:309:13: warning: 'pa' may be used uninitialized in this function [-Wmaybe-uninitialized]
> 
> This adds a bogus initialization to the function to sanitize
> the debug output.  I would have preferred a solution without
> the initialization, but I only got the report from the
> kbuild bot after turning on the warning again, and didn't
> manage to reproduce it myself.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>  arch/s390/pci/pci_dma.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/s390/pci/pci_dma.c b/arch/s390/pci/pci_dma.c
> index 7350c8b..6b2f72f 100644
> --- a/arch/s390/pci/pci_dma.c
> +++ b/arch/s390/pci/pci_dma.c
> @@ -423,7 +423,7 @@ static int __s390_dma_map_sg(struct device *dev, struct scatterlist *sg,
>  	dma_addr_t dma_addr_base, dma_addr;
>  	int flags = ZPCI_PTE_VALID;
>  	struct scatterlist *s;
> -	unsigned long pa;
> +	unsigned long pa = 0;
>  	int ret;
> 
>  	size = PAGE_ALIGN(size);

The compiler is right. pa is set in the for-loop. If "dma_addr < dma_addr_base + size"
is never true and __dma_purge_tlb() returns with an error, pa *is* uninitialized.
The fix seems sensible to me.

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

[toc] | [prev] | [next] | [standalone]

#1502808 — Re: [PATCH 25/28] s390: pci: don't print uninitialized data for debugging

On Tue, 18 Oct 2016, Martin Schwidefsky wrote:
> On Tue, 18 Oct 2016 00:16:13 +0200
> Arnd Bergmann <arnd@arndb.de> wrote:
> 
> > gcc correctly warns about an incorrect use of the 'pa' variable
> > in case we pass an empty scatterlist to __s390_dma_map_sg:
> > 
> > arch/s390/pci/pci_dma.c: In function '__s390_dma_map_sg':
> > arch/s390/pci/pci_dma.c:309:13: warning: 'pa' may be used uninitialized in this function [-Wmaybe-uninitialized]
> > 
> > This adds a bogus initialization to the function to sanitize
> > the debug output.  I would have preferred a solution without
> > the initialization, but I only got the report from the
> > kbuild bot after turning on the warning again, and didn't
> > manage to reproduce it myself.
> > 
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > ---
> >  arch/s390/pci/pci_dma.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/arch/s390/pci/pci_dma.c b/arch/s390/pci/pci_dma.c
> > index 7350c8b..6b2f72f 100644
> > --- a/arch/s390/pci/pci_dma.c
> > +++ b/arch/s390/pci/pci_dma.c
> > @@ -423,7 +423,7 @@ static int __s390_dma_map_sg(struct device *dev, struct scatterlist *sg,
> >  	dma_addr_t dma_addr_base, dma_addr;
> >  	int flags = ZPCI_PTE_VALID;
> >  	struct scatterlist *s;
> > -	unsigned long pa;
> > +	unsigned long pa = 0;
> >  	int ret;
> > 
> >  	size = PAGE_ALIGN(size);
> 
> The compiler is right. pa is set in the for-loop. If "dma_addr < dma_addr_base + size"
> is never true and __dma_purge_tlb() returns with an error, pa *is* uninitialized.
> The fix seems sensible to me.

Although that could only happen if map_sg is called with zero length sg
list entries I'm in favor getting rid of that warning.

Acked-by: Sebastian Ott <sebott@linux.vnet.ibm.com>

Regards,
Sebastian

[toc] | [prev] | [next] | [standalone]

#1502551 — [PATCH 23/28] x86: mark target address as output in 'insb' asm

The -Wmaybe-uninitialized warning triggers for one driver using the output
of the 'insb' I/O helper on x86:

drivers/net/wireless/wl3501_cs.c: In function ‘wl3501_mgmt_scan_confirm’:
drivers/net/wireless/wl3501_cs.c:665:9: error: ‘sig.status’ is used uninitialized in this function [-Werror=uninitialized]
drivers/net/wireless/wl3501_cs.c:668:12: error: ‘sig.cap_info’ may be used uninitialized in this function [-Werror=maybe-uninitialized]

Apparently the assember constraints are slightly off here, as marking the
'addr' argument as a memory output seems appropriate here and gets rid
of the warning. For consistency I'm also adding it as input for outsb().

I'm not an x86 person and gcc inline assembly mystifies me all the time,
so please review this carefully and suggest a better way if this is not
how it should be done.

Cc: x86@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/x86/include/asm/io.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index de25aad..287234c 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -304,13 +304,13 @@ static inline unsigned type in##bwl##_p(int port)			\
 static inline void outs##bwl(int port, const void *addr, unsigned long count) \
 {									\
 	asm volatile("rep; outs" #bwl					\
-		     : "+S"(addr), "+c"(count) : "d"(port));		\
+		     : "+S"(addr), "+c"(count) : "d"(port), "m" (addr));\
 }									\
 									\
 static inline void ins##bwl(int port, void *addr, unsigned long count)	\
 {									\
 	asm volatile("rep; ins" #bwl					\
-		     : "+D"(addr), "+c"(count) : "d"(port));		\
+		     : "+D"(addr), "+c"(count), "=m" (addr) : "d"(port));\
 }
 
 BUILDIO(b, b, char)
-- 
2.9.0

[toc] | [prev] | [next] | [standalone]

#1502552 — [PATCH 28/28] Kbuild: bring back -Wmaybe-uninitialized warning

Traditionally, we have always had warnings about uninitialized variables
enabled, as this is part of -Wall, and generally a good idea [1], but it
also always produced false positives, mainly because this is a variation
of the halting problem and provably impossible to get right in all cases
[2].

Various people have identified cases that are particularly bad for false
positives, and in commit e74fc973b6e5 ("Turn off -Wmaybe-uninitialized
when building with -Os"), I turned off the warning for any build that
was done with CC_OPTIMIZE_FOR_SIZE.  This drastically reduced the number
of false positive warnings in the default build but unfortunately had
the side effect of turning the warning off completely in 'allmodconfig'
builds, which in turn led to a lot of warnings (both actual bugs, and
remaining false positives) to go in unnoticed.

With commit 877417e6ffb9 ("Kbuild: change CC_OPTIMIZE_FOR_SIZE
definition") enabled the warning again for allmodconfig builds in v4.7
and in v4.8-rc1, I had finally managed to address all warnings I get in
an ARM allmodconfig build and most other maybe-uninitialized warnings
for ARM randconfig builds.

However, commit 6e8d666e9253 ("Disable "maybe-uninitialized" warning
globally") was merged at the same time and disabled it completely for
all configurations, because of false-positive warnings on x86 that
I had not addressed until then. This caused a lot of actual bugs to
get merged into mainline, and I sent several dozen patches for these
during the v4.9 development cycle. Most of these are actual bugs,
some are for correct code that is safe because it is only called
under external constraints that make it impossible to run into
the case that gcc sees, and in a few cases gcc is just stupid and
finds something that can obviously never happen.

I have now done a few thousand randconfig builds on x86 and collected
all patches that I needed to address every single warning I got
(I can provide the combined patch for the other warnings if anyone
is interested), so I hope we can get the warning back and let people
catch the actual bugs earlier.

Note that the majority of the patches I created are for the third kind
of problem (stupid false-positives), for one of two reasons:
- some of them only get triggered in certain combinations of config
  options, so we don't always run into them, and
- the actual bugs tend to get addressed much quicker as they also
  lead to incorrect runtime behavior.

These 27 patches address the warnings that either occur in one of the more
common configurations (defconfig, allmodconfig, or something built by the
kbuild robot or kernelci.org), or they are about a real bug. It would be
good to get these all into v4.9 if we want to turn on the warning again.
I have tested these extensively with gcc-4.9 and gcc-6 and done a bit
of testing with gcc-5, and all of these should now be fine. gcc-4.8
is much worse about the false-positive warnings and is also fairly old
now, so I'm leaving the warning disabled with that version. gcc-4.7 and
older don't understand the -Wno-maybe-uninitialized option and are not
affected by this patch either way.

I have another (smaller) series of patches for warnings that are both
harmless and not as easy to trigger, and I will send them for inclusion
in v4.10.

Link: https://rusty.ozlabs.org/?p=232 [1]
Link: https://gcc.gnu.org/wiki/Better_Uninitialized_Warnings [2]
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 Makefile               | 10 ++++++----
 arch/arc/Makefile      |  4 +++-
 scripts/Makefile.ubsan |  4 ++++
 3 files changed, 13 insertions(+), 5 deletions(-)

Cc: x86@kernel.org
Cc: linux-media@vger.kernel.org
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: linux-s390@vger.kernel.org
Cc: Ilya Dryomov <idryomov@gmail.com>
Cc: dri-devel@lists.freedesktop.org
Cc: linux-mtd@lists.infradead.org
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: linux-crypto@vger.kernel.org
Cc: "David S. Miller" <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: ceph-devel@vger.kernel.org
Cc: linux-f2fs-devel@lists.sourceforge.net
Cc: linux-ext4@vger.kernel.org
Cc: netfilter-devel@vger.kernel.org

diff --git a/Makefile b/Makefile
index 512e47a..43cd3d9 100644
--- a/Makefile
+++ b/Makefile
@@ -370,7 +370,7 @@ LDFLAGS_MODULE  =
 CFLAGS_KERNEL	=
 AFLAGS_KERNEL	=
 LDFLAGS_vmlinux =
-CFLAGS_GCOV	= -fprofile-arcs -ftest-coverage -fno-tree-loop-im
+CFLAGS_GCOV	= -fprofile-arcs -ftest-coverage -fno-tree-loop-im  -Wno-maybe-uninitialized
 CFLAGS_KCOV	:= $(call cc-option,-fsanitize-coverage=trace-pc,)
 
 
@@ -620,7 +620,6 @@ ARCH_CFLAGS :=
 include arch/$(SRCARCH)/Makefile
 
 KBUILD_CFLAGS	+= $(call cc-option,-fno-delete-null-pointer-checks,)
-KBUILD_CFLAGS	+= $(call cc-disable-warning,maybe-uninitialized,)
 KBUILD_CFLAGS	+= $(call cc-disable-warning,frame-address,)
 
 ifdef CONFIG_LD_DEAD_CODE_DATA_ELIMINATION
@@ -629,15 +628,18 @@ KBUILD_CFLAGS	+= $(call cc-option,-fdata-sections,)
 endif
 
 ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
-KBUILD_CFLAGS	+= -Os
+KBUILD_CFLAGS	+= -Os $(call cc-disable-warning,maybe-uninitialized,)
 else
 ifdef CONFIG_PROFILE_ALL_BRANCHES
-KBUILD_CFLAGS	+= -O2
+KBUILD_CFLAGS	+= -O2 $(call cc-disable-warning,maybe-uninitialized,)
 else
 KBUILD_CFLAGS   += -O2
 endif
 endif
 
+KBUILD_CFLAGS += $(call cc-ifversion, -lt, 0409, \
+			$(call cc-disable-warning,maybe-uninitialized,))
+
 # Tell gcc to never replace conditional load with a non-conditional one
 KBUILD_CFLAGS	+= $(call cc-option,--param=allow-store-data-races=0)
 
diff --git a/arch/arc/Makefile b/arch/arc/Makefile
index aa82d13..19cce22 100644
--- a/arch/arc/Makefile
+++ b/arch/arc/Makefile
@@ -71,7 +71,9 @@ cflags-$(CONFIG_ARC_DW2_UNWIND)		+= -fasynchronous-unwind-tables $(cfi)
 ifndef CONFIG_CC_OPTIMIZE_FOR_SIZE
 # Generic build system uses -O2, we want -O3
 # Note: No need to add to cflags-y as that happens anyways
-ARCH_CFLAGS += -O3
+#
+# Disable the false maybe-uninitialized warings gcc spits out at -O3
+ARCH_CFLAGS += -O3 $(call cc-disable-warning,maybe-uninitialized,)
 endif
 
 # small data is default for elf32 tool-chain. If not usable, disable it
diff --git a/scripts/Makefile.ubsan b/scripts/Makefile.ubsan
index dd779c4..3b1b138 100644
--- a/scripts/Makefile.ubsan
+++ b/scripts/Makefile.ubsan
@@ -17,4 +17,8 @@ endif
 ifdef CONFIG_UBSAN_NULL
       CFLAGS_UBSAN += $(call cc-option, -fsanitize=null)
 endif
+
+      # -fsanitize=* options makes GCC less smart than usual and
+      # increase number of 'maybe-uninitialized false-positives
+      CFLAGS_UBSAN += $(call cc-option, -Wno-maybe-uninitialized)
 endif
-- 
2.9.0

[toc] | [prev] | [next] | [standalone]

#1502693

On Tue, Oct 18, 2016 at 12:03:28AM +0200, Arnd Bergmann wrote:
> This is a set of patches that I hope to get into v4.9 in some form
> in order to turn on the -Wmaybe-uninitialized warnings again.

Hi Arnd,

I jsut complained to Geert that I was introducing way to many
bugs or pointless warnings for some compilers lately, but gcc didn't
warn me about them.  From a little research the lack of
-Wmaybe-uninitialized seems to be the reason for it, so I'm all
for re-enabling it.

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | linux.kernel

csiph-web