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 1 of 3  [1] 2 3  Next page →

#1502518 — [PATCH 00/28] Reenable maybe-uninitialized warnings

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.

After talking to Linus in person at Linaro Connect about this, I
spent some time on finding all the remaining warnings, and this
is the resulting patch series. More details are in the description
of the last patch that actually enables the warning.

Let me know if there are other warnings that I missed, and whether
you think these are still appropriate for v4.9 or not.
A couple of patches are non-obvious, and could use some more
detailed review.

	Arnd

Arnd Bergmann (28):
  [v2] netfilter: nf_tables: avoid uninitialized variable warning
  [v2] mtd: mtk: avoid warning in mtk_ecc_encode
  [v2] infiniband: shut up a maybe-uninitialized warning
  f2fs: replace a build-time warning with runtime WARN_ON
  ext2: avoid bogus -Wmaybe-uninitialized warning
  NFSv4.1: work around -Wmaybe-uninitialized warning
  ceph: avoid false positive maybe-uninitialized warning
  staging: lustre: restore initialization of return code
  staging: lustre: remove broken dead code in
    cfs_cpt_table_create_pattern
  UBI: fix uninitialized access of vid_hdr pointer
  block: rdb: false-postive gcc-4.9 -Wmaybe-uninitialized
  [media] rc: print correct variable for z8f0811
  [media] dib0700: fix uninitialized data on 'repeat' event
  iio: accel: sca3000_core: avoid potentially uninitialized variable
  crypto: aesni: avoid -Wmaybe-uninitialized warning
  pcmcia: fix return value of soc_pcmcia_regulator_set
  spi: fsl-espi: avoid processing uninitalized data on error
  drm: avoid uninitialized timestamp use in wait_vblank
  brcmfmac: avoid maybe-uninitialized warning in brcmf_cfg80211_start_ap
  net: bcm63xx: avoid referencing uninitialized variable
  net/hyperv: avoid uninitialized variable
  x86: apm: avoid uninitialized data
  x86: mark target address as output in 'insb' asm
  x86: math-emu: possible uninitialized variable use
  s390: pci: don't print uninitialized data for debugging
  nios2: fix timer initcall return value
  rocker: fix maybe-uninitialized warning
  Kbuild: bring back -Wmaybe-uninitialized warning

 Makefile                                           |  10 +-
 arch/arc/Makefile                                  |   4 +-
 arch/nios2/kernel/time.c                           |   1 +
 arch/s390/pci/pci_dma.c                            |   2 +-
 arch/x86/crypto/aesni-intel_glue.c                 | 121 +++++++++++++--------
 arch/x86/include/asm/io.h                          |   4 +-
 arch/x86/kernel/apm_32.c                           |   5 +-
 arch/x86/math-emu/Makefile                         |   4 +-
 arch/x86/math-emu/reg_compare.c                    |  16 +--
 drivers/block/rbd.c                                |   1 +
 drivers/gpu/drm/drm_irq.c                          |   4 +-
 drivers/infiniband/core/cma.c                      |  56 +++++-----
 drivers/media/i2c/ir-kbd-i2c.c                     |   2 +-
 drivers/media/usb/dvb-usb/dib0700_core.c           |  10 +-
 drivers/mtd/nand/mtk_ecc.c                         |  19 ++--
 drivers/mtd/ubi/eba.c                              |   2 +-
 drivers/net/ethernet/broadcom/bcm63xx_enet.c       |   3 +-
 drivers/net/ethernet/rocker/rocker_ofdpa.c         |   4 +-
 drivers/net/hyperv/netvsc_drv.c                    |   2 +-
 .../broadcom/brcm80211/brcmfmac/cfg80211.c         |   2 +-
 drivers/pcmcia/soc_common.c                        |   2 +-
 drivers/spi/spi-fsl-espi.c                         |   2 +-
 drivers/staging/iio/accel/sca3000_core.c           |   2 +
 .../staging/lustre/lnet/libcfs/linux/linux-cpu.c   |   7 --
 drivers/staging/lustre/lustre/lov/lov_pack.c       |   2 +
 fs/ceph/super.c                                    |   3 +-
 fs/ext2/inode.c                                    |   7 +-
 fs/f2fs/data.c                                     |   7 ++
 fs/nfs/nfs4session.c                               |  10 +-
 net/netfilter/nft_range.c                          |  10 +-
 scripts/Makefile.ubsan                             |   4 +
 31 files changed, 187 insertions(+), 141 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
2.9.0

[toc] | [next] | [standalone]

#1502519 — [PATCH 08/28] staging: lustre: restore initialization of return code

A recent rework removed the initialization of the successful return
code from lpfc_write_firmware:

drivers/scsi/lpfc/lpfc_init.c: In function 'lpfc_write_firmware':
drivers/scsi/lpfc/lpfc_init.c:10333:214: error: format '%ld' expects argument of type 'long int', but argument 9 has type 'size_t {aka const unsigned int}' [-Werror=format=]

This adds it back.

Fixes: e10a431b3fd0 ("staging: lustre: lov: move LSM to LOV layer")
Cc: John L. Hammond <john.hammond@intel.com>
Cc: Jinshan Xiong <jinshan.xiong@intel.com>
Cc: James Simmons <jsimmons@infradead.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/staging/lustre/lustre/lov/lov_pack.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/staging/lustre/lustre/lov/lov_pack.c b/drivers/staging/lustre/lustre/lov/lov_pack.c
index be6e985..0439f54 100644
--- a/drivers/staging/lustre/lustre/lov/lov_pack.c
+++ b/drivers/staging/lustre/lustre/lov/lov_pack.c
@@ -474,6 +474,8 @@ int lov_getstripe(struct lov_object *obj, struct lov_stripe_md *lsm,
 	((struct lov_user_md *)lmmk)->lmm_stripe_count = lum.lmm_stripe_count;
 	if (copy_to_user(lump, lmmk, lmm_size))
 		rc = -EFAULT;
+	else
+		rc = 0;
 
 out_free:
 	kfree(lmmk);
-- 
2.9.0

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

#1502563 — Re: [lustre-devel] [PATCH 08/28] staging: lustre: restore initialization of return code

On Mon, Oct 17, 2016 at 3:29 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>
> Sorry, I pasted the wrong error message when writing the changelog.

Not just the warning, the summary above it talks about the wrong
function too. And the commit it references doesn't actually exist
either. So apparently this is against something else than my tree.

               Linus

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

#1502576 — Re: [lustre-devel] [PATCH 08/28] staging: lustre: restore initialization of return code

On Monday, October 17, 2016 3:37:11 PM CEST Linus Torvalds wrote:
> On Mon, Oct 17, 2016 at 3:29 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> >
> > Sorry, I pasted the wrong error message when writing the changelog.
> 
> Not just the warning, the summary above it talks about the wrong
> function too. And the commit it references doesn't actually exist
> either. So apparently this is against something else than my tree.

Right, it slipped in here together with the other lustre patch when
I rebased my longer series (based on linux-next) onto v4.9-rc1.

Both applied cleanly to v4.9-rc1 and they are required on linux-next
(not the version with the wrong changelog of course) but have no
effect in mainline so far.

I'll double-check the rest of the series tomorrow, to see if some
of the other patches also have the same problem and are only
needed on linux-next. I meant to send those as part of the
separate series for v4.10.

For now, it would be good to know if you see any remaining warnings
on your machine after applying the current series (with or without
the lustre patches, doesn't matter) to a test branch. Some other
patches in the series likely need to go through a second revision
anyway.

	Arnd

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

#1502564 — Re: [lustre-devel] [PATCH 08/28] staging: lustre: restore initialization of return code

On Monday, October 17, 2016 10:23:00 PM CEST Patrick Farrell wrote:
> Arnd,
> 
> 
> The description and the actual patch don't seem to match up.  Am I missing something?

Sorry, I pasted the wrong error message when writing the changelog.

> From: lustre-devel <lustre-devel-bounces@lists.lustre.org> on behalf of Arnd Bergmann <arnd@arndb.de>
> Sent: Monday, October 17, 2016 5:08:55 PM
> To: Oleg Drokin
> Cc: devel@driverdev.osuosl.org; Arnd Bergmann; Greg Kroah-Hartman; linux-kernel@vger.kernel.org; Linus Torvalds; lustre-devel@lists.lustre.org
> Subject: [lustre-devel] [PATCH 08/28] staging: lustre: restore initialization of return code
> 
> A recent rework removed the initialization of the successful return
> code from lpfc_write_firmware:
> 
> drivers/scsi/lpfc/lpfc_init.c: In function 'lpfc_write_firmware':
> drivers/scsi/lpfc/lpfc_init.c:10333:214: error: format '%ld' expects argument of type 'long int', but argument 9 has type 'size_t {aka const unsigned int}' [-Werror=format=]
> 
> This adds it back.


It should have been this warning:


drivers/staging/lustre/lustre/lov/lov_pack.c: In function 'lov_getstripe':
drivers/staging/lustre/lustre/lov/lov_pack.c:426:9: error: 'rc' may be used uninitialized in this function [-Werror=maybe-uninitialized]
  return rc;
         ^~
drivers/staging/lustre/lustre/lov/lov_pack.c:313:6: note: 'rc' was declared here


	Arnd

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

#1502567 — [PATCH 08/28 v2] staging: lustre: restore initialization of return code

A recent rework dropped the initialization of the initialization of the
successful return code in lov_getstripe:

drivers/staging/lustre/lustre/lov/lov_pack.c: In function 'lov_getstripe':
drivers/staging/lustre/lustre/lov/lov_pack.c:426:9: error: 'rc' may be used uninitialized in this function [-Werror=maybe-uninitialized]
drivers/staging/lustre/lustre/lov/lov_pack.c:313:6: note: 'rc' was declared here

This adds it back.

Fixes: e10a431b3fd0 ("staging: lustre: lov: move LSM to LOV layer")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
v2: fix embarrassing incorrect changelog

diff --git a/drivers/staging/lustre/lustre/lov/lov_pack.c b/drivers/staging/lustre/lustre/lov/lov_pack.c
index 17bceadd66f8..ccc1fae35791 100644
--- a/drivers/staging/lustre/lustre/lov/lov_pack.c
+++ b/drivers/staging/lustre/lustre/lov/lov_pack.c
@@ -418,6 +418,8 @@ int lov_getstripe(struct lov_object *obj, struct lov_stripe_md *lsm,
 	((struct lov_user_md *)lmmk)->lmm_stripe_count = lum.lmm_stripe_count;
 	if (copy_to_user(lump, lmmk, lmm_size))
 		rc = -EFAULT;
+	else
+		rc = 0;
 
 out_free:
 	kvfree(lmmk);

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

#1502520 — [PATCH 11/28] block: rdb: false-postive gcc-4.9 -Wmaybe-uninitialized

When building with gcc-4.9 -Wmaybe-uninitialized, we get a bogus
warning in rbd_watch_cb, as the variable is not used at all
in the one case in which it is not initialized first:

drivers/block/rbd.c: In function ‘rbd_watch_cb’:
drivers/block/rbd.c:3690:5: error: ‘struct_v’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
drivers/block/rbd.c:3759:5: note: ‘struct_v’ was declared here

Later compiler versions fix this, but adding another initialization
here is harmless and lets us build cleanly with 4.9 as well.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/block/rbd.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/block/rbd.c b/drivers/block/rbd.c
index abb7162..4ab990b 100644
--- a/drivers/block/rbd.c
+++ b/drivers/block/rbd.c
@@ -3776,6 +3776,7 @@ static void rbd_watch_cb(void *arg, u64 notify_id, u64 cookie,
 	} else {
 		/* legacy notification for header updates */
 		notify_op = RBD_NOTIFY_OP_HEADER_UPDATE;
+		struct_v = 0;
 		len = 0;
 	}
 
-- 
2.9.0

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

#1502851 — Re: [PATCH 11/28] block: rdb: false-postive gcc-4.9 -Wmaybe-uninitialized

On Tue, Oct 18, 2016 at 12:10 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> When building with gcc-4.9 -Wmaybe-uninitialized, we get a bogus
> warning in rbd_watch_cb, as the variable is not used at all
> in the one case in which it is not initialized first:
>
> drivers/block/rbd.c: In function ‘rbd_watch_cb’:
> drivers/block/rbd.c:3690:5: error: ‘struct_v’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
> drivers/block/rbd.c:3759:5: note: ‘struct_v’ was declared here
>
> Later compiler versions fix this, but adding another initialization
> here is harmless and lets us build cleanly with 4.9 as well.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>  drivers/block/rbd.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/block/rbd.c b/drivers/block/rbd.c
> index abb7162..4ab990b 100644
> --- a/drivers/block/rbd.c
> +++ b/drivers/block/rbd.c
> @@ -3776,6 +3776,7 @@ static void rbd_watch_cb(void *arg, u64 notify_id, u64 cookie,
>         } else {
>                 /* legacy notification for header updates */
>                 notify_op = RBD_NOTIFY_OP_HEADER_UPDATE;
> +               struct_v = 0;
>                 len = 0;
>         }

It already got silenced by initializing at declaration in one of the
downstream trees, so I'd rather we do

@@ -3756,7 +3819,7 @@ static void rbd_watch_cb(void *arg, u64
notify_id, u64 cookie,
        struct rbd_device *rbd_dev = arg;
        void *p = data;
        void *const end = p + data_len;
-       u8 struct_v;
+       u8 struct_v = 0;
        u32 len;
        u32 notify_op;
        int ret;

to reduce the churn.

The "block" prefix is redundant and "rdb" should be "rbd" in the subject.

Thanks,

                Ilya

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

#1502863 — Re: [PATCH 11/28] block: rdb: false-postive gcc-4.9 -Wmaybe-uninitialized

On Tuesday, October 18, 2016 11:57:33 AM CEST Ilya Dryomov wrote:
> It already got silenced by initializing at declaration in one of the
> downstream trees, so I'd rather we do
> 
> @@ -3756,7 +3819,7 @@ static void rbd_watch_cb(void *arg, u64
> notify_id, u64 cookie,
>         struct rbd_device *rbd_dev = arg;
>         void *p = data;
>         void *const end = p + data_len;
> -       u8 struct_v;
> +       u8 struct_v = 0;
>         u32 len;
>         u32 notify_op;
>         int ret;
> 
> to reduce the churn.

Fair enough. I try to avoid adding extraneous initializations like
this, but my suggested change is not all that different here,
except if ceph_start_decoding() got changed in a way that could
lead to another uninitialized use.

> The "block" prefix is redundant and "rdb" should be "rbd" in the subject.

Oops.

	Arnd

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

#1502521 — [PATCH 21/28] net/hyperv: avoid uninitialized variable

The hdr_offset variable is only if we deal with a TCP or UDP packet,
but as the check surrounding its usage tests for skb_is_gso()
instead, the compiler has no idea if the variable is initialized
or not at that point:

drivers/net/hyperv/netvsc_drv.c: In function ‘netvsc_start_xmit’:
drivers/net/hyperv/netvsc_drv.c:494:42: error: ‘hdr_offset’ may be used uninitialized in this function [-Werror=maybe-uninitialized]

This adds an additional check for the transport type, which
tells the compiler that this path cannot happen. Since the
get_net_transport_info() function should always be inlined
here, I don't expect this to result in additional runtime
checks.

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

diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index f0919bd..5d6e75a 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -447,7 +447,7 @@ static int netvsc_start_xmit(struct sk_buff *skb, struct net_device *net)
 	 * Setup the sendside checksum offload only if this is not a
 	 * GSO packet.
 	 */
-	if (skb_is_gso(skb)) {
+	if ((net_trans_info & (INFO_TCP | INFO_UDP)) && skb_is_gso(skb)) {
 		struct ndis_tcp_lso_info *lso_info;
 
 		rndis_msg_size += NDIS_LSO_PPI_SIZE;
-- 
2.9.0

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

#1503280 — Re: [PATCH 21/28] net/hyperv: avoid uninitialized variable

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

> The hdr_offset variable is only if we deal with a TCP or UDP packet,
> but as the check surrounding its usage tests for skb_is_gso()
> instead, the compiler has no idea if the variable is initialized
> or not at that point:
> 
> drivers/net/hyperv/netvsc_drv.c: In function ‘netvsc_start_xmit’:
> drivers/net/hyperv/netvsc_drv.c:494:42: error: ‘hdr_offset’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
> 
> This adds an additional check for the transport type, which
> tells the compiler that this path cannot happen. Since the
> get_net_transport_info() function should always be inlined
> here, I don't expect this to result in additional runtime
> checks.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Applied.

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

#1502522 — [PATCH 15/28] crypto: aesni: avoid -Wmaybe-uninitialized warning

The rfc4106 encrypy/decrypt helper functions cause an annoying
false-positive warning in allmodconfig if we turn on
-Wmaybe-uninitialized warnings again:

arch/x86/crypto/aesni-intel_glue.c: In function ‘helper_rfc4106_decrypt’:
include/linux/scatterlist.h:67:31: warning: ‘dst_sg_walk.sg’ may be used uninitialized in this function [-Wmaybe-uninitialized]

The problem seems to be that the compiler doesn't track the state of the
'one_entry_in_sg' variable across the kernel_fpu_begin/kernel_fpu_end
section.

This reorganizes the code to avoid that variable and have the shared
code in a separate function to avoid some of the conditional branches.

The resulting functions are a bit longer but also slightly less complex,
leaving no room for speculation on the part of the compiler.

Cc: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
The conversion is nontrivial, and I have only build-tested it, so this
could use a careful review and testing.
---
 arch/x86/crypto/aesni-intel_glue.c | 121 ++++++++++++++++++++++---------------
 1 file changed, 73 insertions(+), 48 deletions(-)

diff --git a/arch/x86/crypto/aesni-intel_glue.c b/arch/x86/crypto/aesni-intel_glue.c
index 0ab5ee1..054155b 100644
--- a/arch/x86/crypto/aesni-intel_glue.c
+++ b/arch/x86/crypto/aesni-intel_glue.c
@@ -269,6 +269,34 @@ static void (*aesni_gcm_dec_tfm)(void *ctx, u8 *out,
 			u8 *hash_subkey, const u8 *aad, unsigned long aad_len,
 			u8 *auth_tag, unsigned long auth_tag_len);
 
+static inline void aesni_do_gcm_enc_tfm(void *ctx, u8 *out,
+			const u8 *in, unsigned long plaintext_len, u8 *iv,
+			u8 *hash_subkey, const u8 *aad, unsigned long aad_len,
+			u8 *auth_tag, unsigned long auth_tag_len)
+{
+	kernel_fpu_begin();
+	aesni_gcm_enc_tfm(ctx, out, in, plaintext_len, iv, hash_subkey,
+			  aad, aad_len, auth_tag, auth_tag_len);
+	kernel_fpu_end();
+}
+
+static inline int aesni_do_gcm_dec_tfm(void *ctx, u8 *out,
+			const u8 *in, unsigned long ciphertext_len, u8 *iv,
+			u8 *hash_subkey, const u8 *aad, unsigned long aad_len,
+			u8 *auth_tag, unsigned long auth_tag_len)
+{
+	kernel_fpu_begin();
+	aesni_gcm_dec_tfm(ctx, out, in, ciphertext_len, iv, hash_subkey, aad,
+			  aad_len, auth_tag, auth_tag_len);
+	kernel_fpu_end();
+
+	/* Compare generated tag with passed in tag. */
+	if (crypto_memneq(in + ciphertext_len, auth_tag, auth_tag_len))
+		return -EBADMSG;
+
+	return 0;
+}
+
 static inline struct
 aesni_rfc4106_gcm_ctx *aesni_rfc4106_gcm_ctx_get(struct crypto_aead *tfm)
 {
@@ -879,7 +907,6 @@ static int rfc4106_set_authsize(struct crypto_aead *parent,
 
 static int helper_rfc4106_encrypt(struct aead_request *req)
 {
-	u8 one_entry_in_sg = 0;
 	u8 *src, *dst, *assoc;
 	__be32 counter = cpu_to_be32(1);
 	struct crypto_aead *tfm = crypto_aead_reqtfm(req);
@@ -908,7 +935,6 @@ static int helper_rfc4106_encrypt(struct aead_request *req)
 	    req->src->offset + req->src->length <= PAGE_SIZE &&
 	    sg_is_last(req->dst) &&
 	    req->dst->offset + req->dst->length <= PAGE_SIZE) {
-		one_entry_in_sg = 1;
 		scatterwalk_start(&src_sg_walk, req->src);
 		assoc = scatterwalk_map(&src_sg_walk);
 		src = assoc + req->assoclen;
@@ -916,7 +942,23 @@ static int helper_rfc4106_encrypt(struct aead_request *req)
 		if (unlikely(req->src != req->dst)) {
 			scatterwalk_start(&dst_sg_walk, req->dst);
 			dst = scatterwalk_map(&dst_sg_walk) + req->assoclen;
+
+			aesni_do_gcm_enc_tfm(aes_ctx, dst, src, req->cryptlen, iv,
+					     ctx->hash_subkey, assoc, req->assoclen - 8,
+					     dst + req->cryptlen, auth_tag_len);
+
+			scatterwalk_unmap(dst - req->assoclen);
+			scatterwalk_advance(&dst_sg_walk, req->dst->length);
+			scatterwalk_done(&dst_sg_walk, 1, 0);
+		} else {
+			aesni_do_gcm_enc_tfm(aes_ctx, dst, src, req->cryptlen, iv,
+					     ctx->hash_subkey, assoc, req->assoclen - 8,
+					     dst + req->cryptlen, auth_tag_len);
 		}
+
+		scatterwalk_unmap(assoc);
+		scatterwalk_advance(&src_sg_walk, req->src->length);
+		scatterwalk_done(&src_sg_walk, req->src == req->dst, 0);
 	} else {
 		/* Allocate memory for src, dst, assoc */
 		assoc = kmalloc(req->cryptlen + auth_tag_len + req->assoclen,
@@ -925,28 +967,14 @@ static int helper_rfc4106_encrypt(struct aead_request *req)
 			return -ENOMEM;
 		scatterwalk_map_and_copy(assoc, req->src, 0,
 					 req->assoclen + req->cryptlen, 0);
-		src = assoc + req->assoclen;
-		dst = src;
-	}
+		dst = src = assoc + req->assoclen;
 
-	kernel_fpu_begin();
-	aesni_gcm_enc_tfm(aes_ctx, dst, src, req->cryptlen, iv,
-			  ctx->hash_subkey, assoc, req->assoclen - 8,
-			  dst + req->cryptlen, auth_tag_len);
-	kernel_fpu_end();
+		aesni_gcm_enc_tfm(aes_ctx, dst, src, req->cryptlen, iv,
+				  ctx->hash_subkey, assoc, req->assoclen - 8,
+				  dst + req->cryptlen, auth_tag_len);
 
-	/* The authTag (aka the Integrity Check Value) needs to be written
-	 * back to the packet. */
-	if (one_entry_in_sg) {
-		if (unlikely(req->src != req->dst)) {
-			scatterwalk_unmap(dst - req->assoclen);
-			scatterwalk_advance(&dst_sg_walk, req->dst->length);
-			scatterwalk_done(&dst_sg_walk, 1, 0);
-		}
-		scatterwalk_unmap(assoc);
-		scatterwalk_advance(&src_sg_walk, req->src->length);
-		scatterwalk_done(&src_sg_walk, req->src == req->dst, 0);
-	} else {
+		/* The authTag (aka the Integrity Check Value) needs to be written
+		 * back to the packet. */
 		scatterwalk_map_and_copy(dst, req->dst, req->assoclen,
 					 req->cryptlen + auth_tag_len, 1);
 		kfree(assoc);
@@ -956,7 +984,6 @@ static int helper_rfc4106_encrypt(struct aead_request *req)
 
 static int helper_rfc4106_decrypt(struct aead_request *req)
 {
-	u8 one_entry_in_sg = 0;
 	u8 *src, *dst, *assoc;
 	unsigned long tempCipherLen = 0;
 	__be32 counter = cpu_to_be32(1);
@@ -990,47 +1017,45 @@ static int helper_rfc4106_decrypt(struct aead_request *req)
 	    req->src->offset + req->src->length <= PAGE_SIZE &&
 	    sg_is_last(req->dst) &&
 	    req->dst->offset + req->dst->length <= PAGE_SIZE) {
-		one_entry_in_sg = 1;
 		scatterwalk_start(&src_sg_walk, req->src);
 		assoc = scatterwalk_map(&src_sg_walk);
 		src = assoc + req->assoclen;
-		dst = src;
 		if (unlikely(req->src != req->dst)) {
 			scatterwalk_start(&dst_sg_walk, req->dst);
 			dst = scatterwalk_map(&dst_sg_walk) + req->assoclen;
-		}
-
-	} else {
-		/* Allocate memory for src, dst, assoc */
-		assoc = kmalloc(req->cryptlen + req->assoclen, GFP_ATOMIC);
-		if (!assoc)
-			return -ENOMEM;
-		scatterwalk_map_and_copy(assoc, req->src, 0,
-					 req->assoclen + req->cryptlen, 0);
-		src = assoc + req->assoclen;
-		dst = src;
-	}
 
-	kernel_fpu_begin();
-	aesni_gcm_dec_tfm(aes_ctx, dst, src, tempCipherLen, iv,
-			  ctx->hash_subkey, assoc, req->assoclen - 8,
-			  authTag, auth_tag_len);
-	kernel_fpu_end();
-
-	/* Compare generated tag with passed in tag. */
-	retval = crypto_memneq(src + tempCipherLen, authTag, auth_tag_len) ?
-		-EBADMSG : 0;
+			retval = aesni_do_gcm_dec_tfm(aes_ctx, dst, src,
+					tempCipherLen, iv, ctx->hash_subkey,
+					assoc, req->assoclen - 8, authTag,
+					auth_tag_len);
 
-	if (one_entry_in_sg) {
-		if (unlikely(req->src != req->dst)) {
 			scatterwalk_unmap(dst - req->assoclen);
 			scatterwalk_advance(&dst_sg_walk, req->dst->length);
 			scatterwalk_done(&dst_sg_walk, 1, 0);
+		} else {
+			dst = src;
+			retval = aesni_do_gcm_dec_tfm(aes_ctx, dst, src,
+					tempCipherLen, iv, ctx->hash_subkey,
+					assoc, req->assoclen - 8, authTag,
+					auth_tag_len);
 		}
 		scatterwalk_unmap(assoc);
 		scatterwalk_advance(&src_sg_walk, req->src->length);
 		scatterwalk_done(&src_sg_walk, req->src == req->dst, 0);
 	} else {
+		/* Allocate memory for src, dst, assoc */
+		assoc = kmalloc(req->cryptlen + req->assoclen, GFP_ATOMIC);
+		if (!assoc)
+			return -ENOMEM;
+		scatterwalk_map_and_copy(assoc, req->src, 0,
+					 req->assoclen + req->cryptlen, 0);
+		dst = src = assoc + req->assoclen;
+
+		retval = aesni_do_gcm_dec_tfm(aes_ctx, dst, src, tempCipherLen,
+					      iv, ctx->hash_subkey, assoc,
+					      req->assoclen - 8, authTag,
+					      auth_tag_len);
+
 		scatterwalk_map_and_copy(dst, req->dst, req->assoclen,
 					 tempCipherLen, 1);
 		kfree(assoc);
-- 
2.9.0

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

#1502524 — [PATCH 19/28] brcmfmac: avoid maybe-uninitialized warning in brcmf_cfg80211_start_ap

A bugfix added a sanity check around the assignment and use of the
'is_11d' variable, which looks correct to me, but as the function is
rather complex already, this confuses the compiler to the point where
it can no longer figure out if the variable is always initialized
correctly:

brcm80211/brcmfmac/cfg80211.c: In function ‘brcmf_cfg80211_start_ap’:
brcm80211/brcmfmac/cfg80211.c:4586:10: error: ‘is_11d’ may be used uninitialized in this function [-Werror=maybe-uninitialized]

This adds an initialization for the newly introduced case in which
the variable should not really be used, in order to make the warning
go away.

Fixes: b3589dfe0212 ("brcmfmac: ignore 11d configuration errors")
Cc: Hante Meuleman <hante.meuleman@broadcom.com>
Cc: Arend van Spriel <arend.vanspriel@broadcom.com>
Cc: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index b777e1b..78d9966 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -4516,7 +4516,7 @@ brcmf_cfg80211_start_ap(struct wiphy *wiphy, struct net_device *ndev,
 	/* store current 11d setting */
 	if (brcmf_fil_cmd_int_get(ifp, BRCMF_C_GET_REGULATORY,
 				  &ifp->vif->is_11d)) {
-		supports_11d = false;
+		is_11d = supports_11d = false;
 	} else {
 		country_ie = brcmf_parse_tlvs((u8 *)settings->beacon.tail,
 					      settings->beacon.tail_len,
-- 
2.9.0

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

#1508835 — Re: [PATCH 19/28] brcmfmac: avoid maybe-uninitialized warning in brcmf_cfg80211_start_ap

Arnd Bergmann <arnd@arndb.de> writes:

> A bugfix added a sanity check around the assignment and use of the
> 'is_11d' variable, which looks correct to me, but as the function is
> rather complex already, this confuses the compiler to the point where
> it can no longer figure out if the variable is always initialized
> correctly:
>
> brcm80211/brcmfmac/cfg80211.c: In function ‘brcmf_cfg80211_start_ap’:
> brcm80211/brcmfmac/cfg80211.c:4586:10: error: ‘is_11d’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
>
> This adds an initialization for the newly introduced case in which
> the variable should not really be used, in order to make the warning
> go away.
>
> Fixes: b3589dfe0212 ("brcmfmac: ignore 11d configuration errors")
> Cc: Hante Meuleman <hante.meuleman@broadcom.com>
> Cc: Arend van Spriel <arend.vanspriel@broadcom.com>
> Cc: Kalle Valo <kvalo@codeaurora.org>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Via which tree are you planning to submit this? Should I take it?

-- 
Kalle Valo

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

#1509016 — Re: [PATCH 19/28] brcmfmac: avoid maybe-uninitialized warning in brcmf_cfg80211_start_ap

On Wednesday, October 26, 2016 9:49:58 AM CEST Kalle Valo wrote:
> Arnd Bergmann <arnd@arndb.de> writes:
> 
> > A bugfix added a sanity check around the assignment and use of the
> > 'is_11d' variable, which looks correct to me, but as the function is
> > rather complex already, this confuses the compiler to the point where
> > it can no longer figure out if the variable is always initialized
> > correctly:
> >
> > brcm80211/brcmfmac/cfg80211.c: In function ‘brcmf_cfg80211_start_ap’:
> > brcm80211/brcmfmac/cfg80211.c:4586:10: error: ‘is_11d’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
> >
> > This adds an initialization for the newly introduced case in which
> > the variable should not really be used, in order to make the warning
> > go away.
> >
> > Fixes: b3589dfe0212 ("brcmfmac: ignore 11d configuration errors")
> > Cc: Hante Meuleman <hante.meuleman@broadcom.com>
> > Cc: Arend van Spriel <arend.vanspriel@broadcom.com>
> > Cc: Kalle Valo <kvalo@codeaurora.org>
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> 
> Via which tree are you planning to submit this? Should I take it?

I'd prefer if you can take it and forward it along with your other
bugfixes. I'll try to take care of the ones that nobody else
picked up.

	Arnd

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

#1509081 — Re: [PATCH 19/28] brcmfmac: avoid maybe-uninitialized warning in brcmf_cfg80211_start_ap

Arnd Bergmann <arnd@arndb.de> writes:

> On Wednesday, October 26, 2016 9:49:58 AM CEST Kalle Valo wrote:
>> Arnd Bergmann <arnd@arndb.de> writes:
>> 
>> > A bugfix added a sanity check around the assignment and use of the
>> > 'is_11d' variable, which looks correct to me, but as the function is
>> > rather complex already, this confuses the compiler to the point where
>> > it can no longer figure out if the variable is always initialized
>> > correctly:
>> >
>> > brcm80211/brcmfmac/cfg80211.c: In function ‘brcmf_cfg80211_start_ap’:
>> > brcm80211/brcmfmac/cfg80211.c:4586:10: error: ‘is_11d’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
>> >
>> > This adds an initialization for the newly introduced case in which
>> > the variable should not really be used, in order to make the warning
>> > go away.
>> >
>> > Fixes: b3589dfe0212 ("brcmfmac: ignore 11d configuration errors")
>> > Cc: Hante Meuleman <hante.meuleman@broadcom.com>
>> > Cc: Arend van Spriel <arend.vanspriel@broadcom.com>
>> > Cc: Kalle Valo <kvalo@codeaurora.org>
>> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>> 
>> Via which tree are you planning to submit this? Should I take it?
>
> I'd prefer if you can take it and forward it along with your other
> bugfixes. I'll try to take care of the ones that nobody else
> picked up.

Ok, I'll take it. I'm planning to push this to 4.9.

-- 
Kalle Valo

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

#1502526 — [PATCH 13/28] [media] dib0700: fix uninitialized data on 'repeat' event

After a recent cleanup patch, "gcc -Wmaybe-uninitialized" reports a new
warning about an existing bug:

drivers/media/usb/dvb-usb/dib0700_core.c: In function ‘dib0700_rc_urb_completion’:
drivers/media/usb/dvb-usb/dib0700_core.c:763:2: error: ‘protocol’ may be used uninitialized in this function [-Werror=maybe-uninitialized]

It turns out that the "0 0 0 FF" sequence of input data has already
caused an uninitialized data use for the keycode variable, but that
was hidden with the 'uninitialized_var()' macro. Now, the protocol
is also uninitialized.

This changes the code to not report any key for this sequence, which
fixes both problems, and allows us to also remove the misleading
uninitialized_var() annotation.

It is possible that we should call rc_repeat() here, but I'm not
sure about that.

Fixes: 2ceeca0499d7 ("[media] rc: split nec protocol into its three variants")
Fixes: d3c501d1938c ("V4L/DVB: dib0700: Fix RC protocol logic to properly handle NEC/NECx and RC-5")
Cc: Sean Young <sean@mess.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/media/usb/dvb-usb/dib0700_core.c | 10 ++++------
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/media/usb/dvb-usb/dib0700_core.c b/drivers/media/usb/dvb-usb/dib0700_core.c
index f319665..3678ebf 100644
--- a/drivers/media/usb/dvb-usb/dib0700_core.c
+++ b/drivers/media/usb/dvb-usb/dib0700_core.c
@@ -677,7 +677,7 @@ static void dib0700_rc_urb_completion(struct urb *purb)
 	struct dvb_usb_device *d = purb->context;
 	struct dib0700_rc_response *poll_reply;
 	enum rc_type protocol;
-	u32 uninitialized_var(keycode);
+	u32 keycode;
 	u8 toggle;
 
 	deb_info("%s()\n", __func__);
@@ -742,11 +742,10 @@ static void dib0700_rc_urb_completion(struct urb *purb)
 			protocol = RC_TYPE_NEC;
 		}
 
+		rc_keydown(d->rc_dev, protocol, keycode, toggle);
 		break;
 	default:
 		deb_data("RC5 protocol\n");
-		protocol = RC_TYPE_RC5;
-		toggle = poll_reply->report_id;
 		keycode = RC_SCANCODE_RC5(poll_reply->rc5.system, poll_reply->rc5.data);
 
 		if ((poll_reply->rc5.data ^ poll_reply->rc5.not_data) != 0xff) {
@@ -754,14 +753,13 @@ static void dib0700_rc_urb_completion(struct urb *purb)
 			err("key failed integrity check: %02x %02x %02x %02x",
 			    poll_reply->rc5.not_used, poll_reply->rc5.system,
 			    poll_reply->rc5.data, poll_reply->rc5.not_data);
-			goto resubmit;
+			break;
 		}
 
+		rc_keydown(d->rc_dev, RC_TYPE_RC5, keycode, poll_reply->report_id);
 		break;
 	}
 
-	rc_keydown(d->rc_dev, protocol, keycode, toggle);
-
 resubmit:
 	/* Clean the buffer before we requeue */
 	memset(purb->transfer_buffer, 0, RC_MSG_SIZE_V1_20);
-- 
2.9.0

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

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

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.

 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);
-- 
2.9.0

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

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

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.
>
>  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>

-mario

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

#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]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | linux.kernel

csiph-web