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
      Re: [19/28] brcmfmac: avoid maybe-uninitialized warning in  brcmf_cfg80211_start_ap Kalle Valo <kvalo@codeaurora.org> - 2016-10-27 17:10 +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 2 of 3 — ← Prev page 1 [2] 3  Next page →

#1502765 — Re: [PATCH 18/28] drm: avoid uninitialized timestamp use in wait_vblank

On Tue, Oct 18, 2016 at 01:47:24AM +0200, Mario Kleiner wrote:
> On 10/18/2016 12:13 AM, Arnd Bergmann wrote:
> > gcc warns about the timestamp in drm_wait_vblank being possibly
> > used without an initialization:
> > 
> > drivers/gpu/drm/drm_irq.c: In function 'drm_crtc_send_vblank_event':
> > drivers/gpu/drm/drm_irq.c:992:24: error: 'now.tv_usec' may be used uninitialized in this function [-Werror=maybe-uninitialized]
> > drivers/gpu/drm/drm_irq.c:1069:17: note: 'now.tv_usec' was declared here
> > drivers/gpu/drm/drm_irq.c:991:23: error: 'now.tv_sec' may be used uninitialized in this function [-Werror=maybe-uninitialized]
> > 
> > This can happen if drm_vblank_count_and_time() returns 0 in its
> > error path. To sanitize the error case, I'm changing that function
> > to return a zero timestamp when it fails.
> > 
> > Fixes: e6ae8687a87b ("drm: idiot-proof vblank")
> > Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
> > Cc: Rob Clark <robdclark@gmail.com>
> > Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > ---
> > First submitted in January 2016, second submission in February,
> > the patch is still required.

Hm, sorry I missed that.

> >  drivers/gpu/drm/drm_irq.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> > index b969a64..48a6167 100644
> > --- a/drivers/gpu/drm/drm_irq.c
> > +++ b/drivers/gpu/drm/drm_irq.c
> > @@ -952,8 +952,10 @@ static u32 drm_vblank_count_and_time(struct drm_device *dev, unsigned int pipe,
> >  	u32 vblank_count;
> >  	unsigned int seq;
> > 
> > -	if (WARN_ON(pipe >= dev->num_crtcs))
> > +	if (WARN_ON(pipe >= dev->num_crtcs)) {
> > +		*vblanktime = (struct timeval) { 0 };
> >  		return 0;
> > +	}
> > 
> >  	do {
> >  		seq = read_seqbegin(&vblank->seqlock);
> > 
> 
> Looks good to me.
> 
> Reviewed-by: Mario Kleiner <mario.kleiner.de@gmail.com>

Applied to drm-misc, thanks.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

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

#1502528 — [PATCH 09/28] staging: lustre: remove broken dead code in cfs_cpt_table_create_pattern

After a recent bugfix, we get a warning about the use of an uninitialized
variable:

drivers/staging/lustre/lnet/libcfs/linux/linux-cpu.c: In function 'cfs_cpt_table_create_pattern':
drivers/staging/lustre/lnet/libcfs/linux/linux-cpu.c:833:7: error: 'str' may be used uninitialized in this function [-Werror=maybe-uninitialized]

This part of the function used to not do anything as we would reassign
the 'str' pointer to something else right away, but now we pass an
uninitialized pointer into 'strchr', which can cause a kernel page fault
or worse.

Fixes: 239fd5d41f9b ("staging: lustre: libcfs: shortcut to create CPT from NUMA topology")
Cc: Liang Zhen <liang.zhen@intel.com>
Cc: James Simmons <jsimmons@infradead.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/staging/lustre/lnet/libcfs/linux/linux-cpu.c | 7 -------
 1 file changed, 7 deletions(-)

diff --git a/drivers/staging/lustre/lnet/libcfs/linux/linux-cpu.c b/drivers/staging/lustre/lnet/libcfs/linux/linux-cpu.c
index e8b1a61..1226cba 100644
--- a/drivers/staging/lustre/lnet/libcfs/linux/linux-cpu.c
+++ b/drivers/staging/lustre/lnet/libcfs/linux/linux-cpu.c
@@ -824,13 +824,6 @@ cfs_cpt_table_create_pattern(char *pattern)
 	int			ncpt;
 	int			c;
 
-	for (ncpt = 0;; ncpt++) { /* quick scan bracket */
-		str = strchr(str, '[');
-		if (!str)
-			break;
-		str++;
-	}
-
 	str = cfs_trimwhite(pattern);
 	if (*str == 'n' || *str == 'N') {
 		pattern = str + 1;
-- 
2.9.0

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

#1502529 — [PATCH 16/28] pcmcia: fix return value of soc_pcmcia_regulator_set

The newly introduced soc_pcmcia_regulator_set() function sometimes returns
without setting its return code, as shown by this warning:

drivers/pcmcia/soc_common.c: In function 'soc_pcmcia_regulator_set':
drivers/pcmcia/soc_common.c:112:5: error: 'ret' may be used uninitialized in this function [-Werror=maybe-uninitialized]

This changes it to propagate the regulator_disable() result instead.

Fixes: ac61b6001a63 ("pcmcia: soc_common: add support for Vcc and Vpp regulators")
Cc: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/pcmcia/soc_common.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pcmcia/soc_common.c b/drivers/pcmcia/soc_common.c
index 153f312..b6b316d 100644
--- a/drivers/pcmcia/soc_common.c
+++ b/drivers/pcmcia/soc_common.c
@@ -107,7 +107,7 @@ int soc_pcmcia_regulator_set(struct soc_pcmcia_socket *skt,
 
 		ret = regulator_enable(r->reg);
 	} else {
-		regulator_disable(r->reg);
+		ret = regulator_disable(r->reg);
 	}
 	if (ret == 0)
 		r->on = on;
-- 
2.9.0

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

#1502831 — Re: [PATCH 16/28] pcmcia: fix return value of soc_pcmcia_regulator_set

On Tue, Oct 18, 2016 at 12:13:37AM +0200, Arnd Bergmann wrote:
> The newly introduced soc_pcmcia_regulator_set() function sometimes returns
> without setting its return code, as shown by this warning:
> 
> drivers/pcmcia/soc_common.c: In function 'soc_pcmcia_regulator_set':
> drivers/pcmcia/soc_common.c:112:5: error: 'ret' may be used uninitialized in this function [-Werror=maybe-uninitialized]
> 
> This changes it to propagate the regulator_disable() result instead.

I guess this is the problem with the stupid patch which silences this
warning - I don't see this warning here.

Having this warning disabled means that _real_ coding errors end up
making their way into the kernel (yes, this should be an error, this
is not a warning, because the value of 'ret' is completely undefined,
and therefore the behaviour of the following code is undefined.)

With the warning silenced, it means that such errors are undetectable.
I knew nothing about this until I received this patch, and I always
check that the code I send is warning-free on the GCC I'm using.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

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

#1502530 — [PATCH 20/28] net: bcm63xx: avoid referencing uninitialized variable

gcc found a reference to an uninitialized variable in the error handling
of bcm_enet_open, introduced by a recent cleanup:

drivers/net/ethernet/broadcom/bcm63xx_enet.c: In function 'bcm_enet_open'
drivers/net/ethernet/broadcom/bcm63xx_enet.c:1129:2: warning: 'phydev' may be used uninitialized in this function [-Wmaybe-uninitialized]

This makes the use of that variable conditional, so we only reference it
here after it has been used before. Unlike my normal patches, I have not
build-tested this one, as I don't currently have mips test in my
randconfig setup.

Fixes: 625eb8667d6f ("net: ethernet: broadcom: bcm63xx: use phydev from struct net_device")
Cc: Philippe Reynes <tremyfr@gmail.com>
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/net/ethernet/broadcom/bcm63xx_enet.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/broadcom/bcm63xx_enet.c b/drivers/net/ethernet/broadcom/bcm63xx_enet.c
index ae364c7..5370909 100644
--- a/drivers/net/ethernet/broadcom/bcm63xx_enet.c
+++ b/drivers/net/ethernet/broadcom/bcm63xx_enet.c
@@ -1126,7 +1126,8 @@ static int bcm_enet_open(struct net_device *dev)
 	free_irq(dev->irq, dev);
 
 out_phy_disconnect:
-	phy_disconnect(phydev);
+	if (priv->has_phy)
+		phy_disconnect(phydev);
 
 	return ret;
 }
-- 
2.9.0

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

#1503279 — Re: [PATCH 20/28] net: bcm63xx: avoid referencing uninitialized variable

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

> gcc found a reference to an uninitialized variable in the error handling
> of bcm_enet_open, introduced by a recent cleanup:
> 
> drivers/net/ethernet/broadcom/bcm63xx_enet.c: In function 'bcm_enet_open'
> drivers/net/ethernet/broadcom/bcm63xx_enet.c:1129:2: warning: 'phydev' may be used uninitialized in this function [-Wmaybe-uninitialized]
> 
> This makes the use of that variable conditional, so we only reference it
> here after it has been used before. Unlike my normal patches, I have not
> build-tested this one, as I don't currently have mips test in my
> randconfig setup.
> 
> Fixes: 625eb8667d6f ("net: ethernet: broadcom: bcm63xx: use phydev from struct net_device")
> Cc: Philippe Reynes <tremyfr@gmail.com>
> Reported-by: kbuild test robot <fengguang.wu@intel.com>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Applied.

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

#1502531 — [PATCH 12/28] [media] rc: print correct variable for z8f0811

A recent rework accidentally left a debugging printk untouched
while changing the meaning of the variables, leading to an
uninitialized variable being printed:

drivers/media/i2c/ir-kbd-i2c.c: In function 'get_key_haup_common':
drivers/media/i2c/ir-kbd-i2c.c:62:2: error: 'toggle' may be used uninitialized in this function [-Werror=maybe-uninitialized]

This prints the correct one instead, as we did before the patch.

Fixes: 00bb820755ed ("[media] rc: Hauppauge z8f0811 can decode RC6")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/media/i2c/ir-kbd-i2c.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/i2c/ir-kbd-i2c.c b/drivers/media/i2c/ir-kbd-i2c.c
index f95a6bc..cede397 100644
--- a/drivers/media/i2c/ir-kbd-i2c.c
+++ b/drivers/media/i2c/ir-kbd-i2c.c
@@ -118,7 +118,7 @@ static int get_key_haup_common(struct IR_i2c *ir, enum rc_type *protocol,
 			*protocol = RC_TYPE_RC6_MCE;
 			dev &= 0x7f;
 			dprintk(1, "ir hauppauge (rc6-mce): t%d vendor=%d dev=%d code=%d\n",
-						toggle, vendor, dev, code);
+						*ptoggle, vendor, dev, code);
 		} else {
 			*ptoggle = 0;
 			*protocol = RC_TYPE_RC6_6A_32;
-- 
2.9.0

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

#1502534 — [PATCH 17/28] spi: fsl-espi: avoid processing uninitalized data on error

When we get a spurious interrupt in fsl_espi_irq, we end up
processing four uninitalized bytes of data, as shown in this
warning message:

   drivers/spi/spi-fsl-espi.c: In function 'fsl_espi_irq':
   drivers/spi/spi-fsl-espi.c:462:4: warning: 'rx_data' may be used uninitialized in this function [-Wmaybe-uninitialized]

This adds another check so we skip the data in this case.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/spi/spi-fsl-espi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/spi-fsl-espi.c b/drivers/spi/spi-fsl-espi.c
index 7451585..2c175b9 100644
--- a/drivers/spi/spi-fsl-espi.c
+++ b/drivers/spi/spi-fsl-espi.c
@@ -458,7 +458,7 @@ static void fsl_espi_cpu_irq(struct mpc8xxx_spi *mspi, u32 events)
 
 		mspi->len -= rx_nr_bytes;
 
-		if (mspi->rx)
+		if (rx_nr_bytes && mspi->rx)
 			mspi->get_rx(rx_data, mspi);
 	}
 
-- 
2.9.0

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

#1507571 — Re: [PATCH 17/28] spi: fsl-espi: avoid processing uninitalized data on error

Am 24.10.2016 um 19:27 schrieb Mark Brown:
> On Tue, Oct 18, 2016 at 12:13:38AM +0200, Arnd Bergmann wrote:
>> When we get a spurious interrupt in fsl_espi_irq, we end up
>> processing four uninitalized bytes of data, as shown in this
>> warning message:
> 
> This doesn't apply against current code, please check and resend.
> 
The not yet reviewed part of my patch series from Oct 2nd,
namely "[PATCH 07/11] spi: fsl-espi: fix and improve reading
from RX FIFO" replaces the code in question.
There's more to fix like removing polling from the ISR.
If you prefer to apply Arnd's fix first I'd rebase the open part
of the patch series and resend it.

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

#1507576 — Re: [PATCH 17/28] spi: fsl-espi: avoid processing uninitalized data on error

[Multipart message — attachments visible in raw view] — view raw

On Mon, Oct 24, 2016 at 08:36:37PM +0200, Heiner Kallweit wrote:
> Am 24.10.2016 um 19:27 schrieb Mark Brown:

> > This doesn't apply against current code, please check and resend.

> The not yet reviewed part of my patch series from Oct 2nd,
> namely "[PATCH 07/11] spi: fsl-espi: fix and improve reading
> from RX FIFO" replaces the code in question.
> There's more to fix like removing polling from the ISR.
> If you prefer to apply Arnd's fix first I'd rebase the open part
> of the patch series and resend it.

If there are dependencies you should mention them when you resend (in
general you should always mention any unapplied or cross tree
dependencies when sending things).

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

#1507707 — Re: [PATCH 17/28] spi: fsl-espi: avoid processing uninitalized data on error

On Monday, October 24, 2016 7:45:43 PM CEST Mark Brown wrote:
> On Mon, Oct 24, 2016 at 08:36:37PM +0200, Heiner Kallweit wrote:
> > Am 24.10.2016 um 19:27 schrieb Mark Brown:
> 
> > > This doesn't apply against current code, please check and resend.
> 
> > The not yet reviewed part of my patch series from Oct 2nd,
> > namely "[PATCH 07/11] spi: fsl-espi: fix and improve reading
> > from RX FIFO" replaces the code in question.
> > There's more to fix like removing polling from the ISR.
> > If you prefer to apply Arnd's fix first I'd rebase the open part
> > of the patch series and resend it.
> 
> If there are dependencies you should mention them when you resend (in
> general you should always mention any unapplied or cross tree
> dependencies when sending things).

I think my patch (the version I sent) should ideally make it into
v4.9 as a bugfix. This was the powerpc warning I saw from Olof's
autobuilder with the -Wmaybe-uninitialized warning added back, and
it's one of the actual bugs I found (though rather unlikely
to hit in practice).

Merging with Heiner's patches should be trivial, and I'm pretty
sure we want the patch either way. Not sure if we need a backport,
it was introduced earlier this year in commit 6319a68011b8
("spi/fsl-espi: avoid infinite loops on fsl_espi_cpu_irq()") as
I now found.

	Arnd

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

#1508565 — Re: [PATCH 17/28] spi: fsl-espi: avoid processing uninitalized data on error

[Multipart message — attachments visible in raw view] — view raw

On Mon, Oct 24, 2016 at 10:37:53PM +0200, Arnd Bergmann wrote:

> I think my patch (the version I sent) should ideally make it into
> v4.9 as a bugfix. This was the powerpc warning I saw from Olof's
> autobuilder with the -Wmaybe-uninitialized warning added back, and
> it's one of the actual bugs I found (though rather unlikely
> to hit in practice).

> Merging with Heiner's patches should be trivial, and I'm pretty
> sure we want the patch either way. Not sure if we need a backport,
> it was introduced earlier this year in commit 6319a68011b8
> ("spi/fsl-espi: avoid infinite loops on fsl_espi_cpu_irq()") as
> I now found.

Sorry but I've lost track of which patches are being talked about here.
If there's stuff for v4.9 can you send me a version that applies on
Linus' tree and I'll merge that up into what's applied for -next?

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

#1508621 — Re: [PATCH 17/28] spi: fsl-espi: avoid processing uninitalized data on error

On Tuesday, October 25, 2016 8:13:09 PM CEST Mark Brown wrote:
> 
> Not enough information to check signature validity.	Show Details
> On Mon, Oct 24, 2016 at 10:37:53PM +0200, Arnd Bergmann wrote:
> 
> > I think my patch (the version I sent) should ideally make it into
> > v4.9 as a bugfix. This was the powerpc warning I saw from Olof's
> > autobuilder with the -Wmaybe-uninitialized warning added back, and
> > it's one of the actual bugs I found (though rather unlikely
> > to hit in practice).
> 
> > Merging with Heiner's patches should be trivial, and I'm pretty
> > sure we want the patch either way. Not sure if we need a backport,
> > it was introduced earlier this year in commit 6319a68011b8
> > ("spi/fsl-espi: avoid infinite loops on fsl_espi_cpu_irq()") as
> > I now found.
> 
> Sorry but I've lost track of which patches are being talked about here.
> If there's stuff for v4.9 can you send me a version that applies on
> Linus' tree and I'll merge that up into what's applied for -next?
> 

Done.

	Arnd

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

#1507597 — Re: [PATCH 17/28] spi: fsl-espi: avoid processing uninitalized data on error

[Multipart message — attachments visible in raw view] — view raw

On Tue, Oct 18, 2016 at 12:13:38AM +0200, Arnd Bergmann wrote:
> When we get a spurious interrupt in fsl_espi_irq, we end up
> processing four uninitalized bytes of data, as shown in this
> warning message:

This doesn't apply against current code, please check and resend.

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

#1509036 — Applied "spi: fsl-espi: avoid processing uninitalized data on error" to the spi tree

The patch

   spi: fsl-espi: avoid processing uninitalized data on error

has been applied to the spi tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

From 5c0ba57744b1422d528f19430dd66d6803cea86f Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd@arndb.de>
Date: Tue, 25 Oct 2016 22:57:10 +0200
Subject: [PATCH] spi: fsl-espi: avoid processing uninitalized data on error

When we get a spurious interrupt in fsl_espi_irq, we end up
processing four uninitalized bytes of data, as shown in this
warning message:

   drivers/spi/spi-fsl-espi.c: In function 'fsl_espi_irq':
   drivers/spi/spi-fsl-espi.c:462:4: warning: 'rx_data' may be used uninitialized in this function [-Wmaybe-uninitialized]

This adds another check so we skip the data in this case.

Fixes: 6319a68011b8 ("spi/fsl-espi: avoid infinite loops on fsl_espi_cpu_irq()")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
---
 drivers/spi/spi-fsl-espi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/spi-fsl-espi.c b/drivers/spi/spi-fsl-espi.c
index 7451585a080e..2c175b9495f7 100644
--- a/drivers/spi/spi-fsl-espi.c
+++ b/drivers/spi/spi-fsl-espi.c
@@ -458,7 +458,7 @@ static void fsl_espi_cpu_irq(struct mpc8xxx_spi *mspi, u32 events)
 
 		mspi->len -= rx_nr_bytes;
 
-		if (mspi->rx)
+		if (rx_nr_bytes && mspi->rx)
 			mspi->get_rx(rx_data, mspi);
 	}
 
-- 
2.8.1

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

#1509686 — Merge problem: Re: Applied "spi: fsl-espi: avoid processing uninitalized data on error" to the spi tree

Am 26.10.2016 um 12:15 schrieb Mark Brown:
> The patch
> 
>    spi: fsl-espi: avoid processing uninitalized data on error
> 
> has been applied to the spi tree at
> 
>    git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git 
> 
> All being well this means that it will be integrated into the linux-next
> tree (usually sometime in the next 24 hours) and sent to Linus during
> the next merge window (or sooner if it is a bug fix), however if
> problems are discovered then the patch may be dropped or reverted.  
> 
> You may get further e-mails resulting from automated or manual testing
> and review of the tree, please engage with people reporting problems and
> send followup patches addressing any issues that are reported if needed.
> 
> If any updates are required or you are submitting further changes they
> should be sent as incremental updates against current git, existing
> patches will not be replaced.
> 
> Please add any relevant lists and maintainers to the CCs when replying
> to this mail.
> 
> Thanks,
> Mark
> 
>>From 5c0ba57744b1422d528f19430dd66d6803cea86f Mon Sep 17 00:00:00 2001
> From: Arnd Bergmann <arnd@arndb.de>
> Date: Tue, 25 Oct 2016 22:57:10 +0200
> Subject: [PATCH] spi: fsl-espi: avoid processing uninitalized data on error
> 
> When we get a spurious interrupt in fsl_espi_irq, we end up
> processing four uninitalized bytes of data, as shown in this
> warning message:
> 
>    drivers/spi/spi-fsl-espi.c: In function 'fsl_espi_irq':
>    drivers/spi/spi-fsl-espi.c:462:4: warning: 'rx_data' may be used uninitialized in this function [-Wmaybe-uninitialized]
> 
> This adds another check so we skip the data in this case.
> 
> Fixes: 6319a68011b8 ("spi/fsl-espi: avoid infinite loops on fsl_espi_cpu_irq()")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Mark Brown <broonie@kernel.org>
> Cc: stable@vger.kernel.org
> ---
>  drivers/spi/spi-fsl-espi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/spi/spi-fsl-espi.c b/drivers/spi/spi-fsl-espi.c
> index 7451585a080e..2c175b9495f7 100644
> --- a/drivers/spi/spi-fsl-espi.c
> +++ b/drivers/spi/spi-fsl-espi.c
> @@ -458,7 +458,7 @@ static void fsl_espi_cpu_irq(struct mpc8xxx_spi *mspi, u32 events)
>  
>  		mspi->len -= rx_nr_bytes;
>  
> -		if (mspi->rx)
> +		if (rx_nr_bytes && mspi->rx)
>  			mspi->get_rx(rx_data, mspi);
>  	}
>  
> 
There seems to be a merge problem. Before the relevant code was:
(changed in recent commit "spi: fsl-espi: fix handling of word
sizes other than 8 bit")

if (mspi->rx) {
	*(u32 *)mspi->rx = rx_data;
	mspi->rx += 4;
}

Now it's:

if (rx_nr_bytes && mspi->rx) {
	mspi->get_rx(rx_data, mspi);
	mspi->rx += 4;
}

Instead it should be:

if (rx_nr_bytes && mspi->rx) {
	*(u32 *)mspi->rx = rx_data;
	mspi->rx += 4;
}

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

#1509879 — Re: Merge problem: Re: Applied "spi: fsl-espi: avoid processing uninitalized data on error" to the spi tree

[Multipart message — attachments visible in raw view] — view raw

On Wed, Oct 26, 2016 at 08:11:28PM +0200, Heiner Kallweit wrote:

> Instead it should be:
> 
> if (rx_nr_bytes && mspi->rx) {
> 	*(u32 *)mspi->rx = rx_data;
> 	mspi->rx += 4;
> }

Please send a patch.

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

#1502536 — [PATCH 10/28] UBI: fix uninitialized access of vid_hdr pointer

A rework of UBI that just appeared in linux-next during the merge
window introduced caused the recover_peb to use a variable that
is never initialized as seen from this gcc warning:

drivers/mtd/ubi/eba.c: In function ‘recover_peb’:
drivers/mtd/ubi/eba.c:744:40: error: ‘vid_hdr’ may be used uninitialized in this function [-Werror=maybe-uninitialized]

It seems clear that the change to the function arguments was missing
the initialization that I'm now adding back to restore the
way the function was working before.

Fixes: 3291b52f9ff0 ("UBI: introduce the VID buffer concept")
Cc: Boris Brezillon <boris.brezillon@free-electrons.com>
Cc: Richard Weinberger <richard@nod.at>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/mtd/ubi/eba.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/ubi/eba.c b/drivers/mtd/ubi/eba.c
index 95c4048..2e152be 100644
--- a/drivers/mtd/ubi/eba.c
+++ b/drivers/mtd/ubi/eba.c
@@ -719,7 +719,7 @@ static int try_recover_peb(struct ubi_volume *vol, int pnum, int lnum,
 			   struct ubi_vid_io_buf *vidb, bool *retry)
 {
 	struct ubi_device *ubi = vol->ubi;
-	struct ubi_vid_hdr *vid_hdr;
+	struct ubi_vid_hdr *vid_hdr = ubi_get_vid_hdr(vidb);
 	int new_pnum, err, vol_id = vol->vol_id, data_size;
 	uint32_t crc;
 
-- 
2.9.0

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

#1502694 — Re: [PATCH 10/28] UBI: fix uninitialized access of vid_hdr pointer

Hi Arnd,

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

> A rework of UBI that just appeared in linux-next during the merge
> window introduced caused the recover_peb to use a variable that
> is never initialized as seen from this gcc warning:
> 
> drivers/mtd/ubi/eba.c: In function ‘recover_peb’:
> drivers/mtd/ubi/eba.c:744:40: error: ‘vid_hdr’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
> 
> It seems clear that the change to the function arguments was missing
> the initialization that I'm now adding back to restore the
> way the function was working before.

Thanks for the fix, but Geert already sent a patch for this bug a few
days ago.

Regards,

Boris

> 
> Fixes: 3291b52f9ff0 ("UBI: introduce the VID buffer concept")
> Cc: Boris Brezillon <boris.brezillon@free-electrons.com>
> Cc: Richard Weinberger <richard@nod.at>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>  drivers/mtd/ubi/eba.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/mtd/ubi/eba.c b/drivers/mtd/ubi/eba.c
> index 95c4048..2e152be 100644
> --- a/drivers/mtd/ubi/eba.c
> +++ b/drivers/mtd/ubi/eba.c
> @@ -719,7 +719,7 @@ static int try_recover_peb(struct ubi_volume *vol, int pnum, int lnum,
>  			   struct ubi_vid_io_buf *vidb, bool *retry)
>  {
>  	struct ubi_device *ubi = vol->ubi;
> -	struct ubi_vid_hdr *vid_hdr;
> +	struct ubi_vid_hdr *vid_hdr = ubi_get_vid_hdr(vidb);
>  	int new_pnum, err, vol_id = vol->vol_id, data_size;
>  	uint32_t crc;
>  

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

#1502538 — [PATCH 14/28] iio: accel: sca3000_core: avoid potentially uninitialized variable

The newly added __sca3000_get_base_freq function handles all valid
modes of the SCA3000_REG_ADDR_MODE register, but gcc notices
that any other value (i.e. 0x00) causes the base_freq variable to
not get initialized:

drivers/staging/iio/accel/sca3000_core.c: In function 'sca3000_write_raw':
drivers/staging/iio/accel/sca3000_core.c:527:23: error: 'base_freq' may be used uninitialized in this function [-Werror=maybe-uninitialized]

This adds explicit error handling for unexpected register values,
to ensure this cannot happen.

Fixes: e0f3fc9b47e6 ("iio: accel: sca3000_core: implemented IIO_CHAN_INFO_SAMP_FREQ")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Ico Doornekamp <ico@pruts.nl>
Cc: Jonathan Cameron <jic23@kernel.org>
---
I submitted this on Sept 22, and Jonathan said he applied it to his
'togreg' tree, but it hasn't appeared in linux-next yet, presumably
since this was not considered material for v4.9.

If we enable the warning again by default, we may want to have the
fix merged for v4.9 after all.

 drivers/staging/iio/accel/sca3000_core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/staging/iio/accel/sca3000_core.c b/drivers/staging/iio/accel/sca3000_core.c
index d626125..564b36d 100644
--- a/drivers/staging/iio/accel/sca3000_core.c
+++ b/drivers/staging/iio/accel/sca3000_core.c
@@ -468,6 +468,8 @@ static inline int __sca3000_get_base_freq(struct sca3000_state *st,
 	case SCA3000_MEAS_MODE_OP_2:
 		*base_freq = info->option_mode_2_freq;
 		break;
+	default:
+		ret = -EINVAL;
 	}
 error_ret:
 	return ret;
-- 
2.9.0

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

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

Back to top | Article view | linux.kernel

csiph-web