1. 12 11月, 2016 10 次提交
    • A
      pcmcia: fix return value of soc_pcmcia_regulator_set · 75ed2687
      Arnd Bergmann 提交于
      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: ac61b600 ("pcmcia: soc_common: add support for Vcc and Vpp regulators")
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      75ed2687
    • A
      infiniband: shut up a maybe-uninitialized warning · c50e90d0
      Arnd Bergmann 提交于
      Some configurations produce this harmless warning when built with gcc
      -Wmaybe-uninitialized:
      
        infiniband/core/cma.c: In function 'cma_get_net_dev':
        infiniband/core/cma.c:1242:12: warning: 'src_addr_storage.sin_addr.s_addr' may be used uninitialized in this function [-Wmaybe-uninitialized]
      
      I previously reported this for the powerpc64 defconfig, but have now
      reproduced the same thing for x86 as well, using gcc-5 or higher.
      
      The code looks correct to me, and this change just rearranges it by
      making sure we alway initialize the entire address structure to make the
      warning disappear.  My first approach added an initialization at the
      time of the declaration, which Doug commented may be too costly, so I
      hope this version doesn't add overhead.
      
      Link: http://arm-soc.lixom.net/buildlogs/mainline/v4.7-rc6/buildall.powerpc.ppc64_defconfig.log.passed
      Link: https://patchwork.kernel.org/patch/9212825/Acked-by: NHaggai Eran <haggaie@mellanox.com>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c50e90d0
    • A
      crypto: aesni: shut up -Wmaybe-uninitialized warning · beae2c9e
      Arnd Bergmann 提交于
      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 takes the easy way out by adding a bogus initialization, which
      should be harmless enough to get the patch into v4.9 so we can turn on
      this warning again by default without producing useless output.  A
      follow-up patch for v4.10 rearranges the code to make the warning go
      away.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      beae2c9e
    • A
      rc: print correct variable for z8f0811 · 9cdbe14f
      Arnd Bergmann 提交于
      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: 00bb8207 ("[media] rc: Hauppauge z8f0811 can decode RC6")
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9cdbe14f
    • S
      dib0700: fix nec repeat handling · ba13e98f
      Sean Young 提交于
      When receiving a nec repeat, ensure the correct scancode is repeated
      rather than a random value from the stack.  This removes the need for
      the bogus uninitialized_var() and also fixes the warnings:
      
          drivers/media/usb/dvb-usb/dib0700_core.c: In function ‘dib0700_rc_urb_completion’:
          drivers/media/usb/dvb-usb/dib0700_core.c:679: warning: ‘protocol’ may be used uninitialized in this function
      
      [sean addon: So after writing the patch and submitting it, I've bought the
                   hardware on ebay. Without this patch you get random scancodes
                   on nec repeats, which the patch indeed fixes.]
      Signed-off-by: NSean Young <sean@mess.org>
      Tested-by: NSean Young <sean@mess.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ba13e98f
    • A
      s390: pci: don't print uninitialized data for debugging · 92dfffee
      Arnd Bergmann 提交于
      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: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NSebastian Ott <sebott@linux.vnet.ibm.com>
      Acked-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      92dfffee
    • A
      nios2: fix timer initcall return value · 069013a9
      Arnd Bergmann 提交于
      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.
      Acked-by: NLey Foon Tan <lftan@altera.com>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      069013a9
    • A
      x86: apm: avoid uninitialized data · 3a6d8676
      Arnd Bergmann 提交于
      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.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Reviewed-by: NJiri Kosina <jkosina@suse.cz>
      Reviewed-by: NLuis R. Rodriguez <mcgrof@kernel.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3a6d8676
    • A
      NFSv4.1: work around -Wmaybe-uninitialized warning · e84efa32
      Arnd Bergmann 提交于
      A bugfix introduced a harmless gcc warning in nfs4_slot_seqid_in_use if
      we enable -Wmaybe-uninitialized again:
      
        fs/nfs/nfs4session.c:203:54: error: 'cur_seq' may be used uninitialized in this function [-Werror=maybe-uninitialized]
      
      gcc is not smart enough to conclude that the IS_ERR/PTR_ERR pair results
      in a nonzero return value here.  Using PTR_ERR_OR_ZERO() instead makes
      this clear to the compiler.
      
      Fixes: e09c978a ("NFSv4.1: Fix Oopsable condition in server callback races")
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e84efa32
    • A
      Kbuild: enable -Wmaybe-uninitialized warning for "make W=1" · a76bcf55
      Arnd Bergmann 提交于
      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 e74fc973 ("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 877417e6 ("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 6e8d666e ("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.
      
      This reverts the change to disable the warning completely and for now
      brings it back at the "make W=1" level, so we can get it merged into
      mainline without introducing false positives.  A follow-up patch enables
      it on all levels unless some configuration option turns it off because
      of false-positives.
      
      Link: https://rusty.ozlabs.org/?p=232 [1]
      Link: https://gcc.gnu.org/wiki/Better_Uninitialized_Warnings [2]
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a76bcf55
  2. 10 11月, 2016 3 次提交
    • L
      Merge tag 'sound-4.9-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound · 27bcd37e
      Linus Torvalds 提交于
      Pull sound fixes from Takashi Iwai:
       "This became a largish pull-request, as we've got a bunch of pending
        ASoC fixes at this time. One noticeable change is the removal of error
        directive in uapi/sound/asoc.h. We found that the API has been already
        used on Chromebooks, so we need to support it even now.
      
        A slight big LOC is found in Qualcomm lpass driver, but the rest are
        all small and easy fixes for ASoC drivers (sti, sun4i, Realtek codecs,
        Intel, tas571x, etc) in addition to the patches to harden the ALSA
        core proc file accesses"
      
      * tag 'sound-4.9-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (26 commits)
        ALSA: info: Return error for invalid read/write
        ALSA: info: Limit the proc text input size
        ASoC: samsung: spdif: Fix DMA filter initialization
        ASoC: sun4i-codec: Enable bus clock after getting GPIO
        ASoC: lpass-cpu: add module licence and description
        ASoC: lpass-platform: Fix broken pcm data usage
        ASoC: sun4i-codec: return error code instead of NULL when create_card fails
        ASoC: hdmi-codec: Fix hdmi_of_xlate_dai_name when #sound-dai-cells = <0>
        ASoC: samsung: get access to DMA engine early to defer probe properly
        ASoC: da7219: Connect output enable register to DAIOUT
        ASoC: Intel: Skylake: Fix to turn off hdmi power on probe failure
        ASoC: sti-sas: enable fast io for regmap
        ASoC: sti: fix channel status update after playback start
        ASoC: PXA: Brownstone needs I2C
        ASoC: Intel: Skylake: Always acquire runtime pm ref on unload
        ASoC: Intel: Atom: add terminate entry for dmi_system_id tables
        ASoC: rt298: fix jack type detect error
        ASoC: rt5663: fix a debug statement
        ASoC: cs4270: fix DAPM stream name mismatch
        ASoC: Intel: haswell depends on sst-firmware
        ...
      27bcd37e
    • L
      Merge tag 'for-linus-4.9-rc4-ofs-1' of git://git.kernel.org/pub/scm/linux/kernel/git/hubcap/linux · 3c6106da
      Linus Torvalds 提交于
      Pull orangefs fix from Mike Marshall:
       "We recently refactored the Orangefs debugfs code. The refactor seemed
        to trigger dan.carpenter@oracle.com's static tester to find a possible
        double-free in the code.
      
        While designing the fix we saw a condition under which the buffer
        being freed could also be overflowed.
      
        We also realized how to rebuild the related debugfs file's "contents"
        (a string) without deleting and re-creating the file.
      
        This fix should eliminate the possible double-free, the potential
        overflow and improve code readability"
      
      * tag 'for-linus-4.9-rc4-ofs-1' of git://git.kernel.org/pub/scm/linux/kernel/git/hubcap/linux:
        orangefs: clean up debugfs
      3c6106da
    • L
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux · ae67e87f
      Linus Torvalds 提交于
      Pull s390 fixes from Martin Schwidefsky:
       "Two bug fixes
      
         - a memory alignment fix in the s390 only hypfs code
      
         - a fix for the generic percpu code that caused ftrace to break on
           s390. This is not relevant for x86 but for all architectures that
           use the generic percpu code"
      
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
        percpu: use notrace variant of preempt_disable/preempt_enable
        s390/hypfs: Use get_free_page() instead of kmalloc to ensure page alignment
      ae67e87f
  3. 09 11月, 2016 1 次提交
  4. 08 11月, 2016 12 次提交
  5. 07 11月, 2016 2 次提交
    • M
      orangefs: clean up debugfs · dc033621
      Mike Marshall 提交于
      We recently refactored the Orangefs debugfs code.
      The refactor seemed to trigger dan.carpenter@oracle.com's
      static tester to find a possible double-free in the code.
      
      While designing the fix we saw a condition under which the
      buffer being freed could also be overflowed.
      
      We also realized how to rebuild the related debugfs file's
      "contents" (a string) without deleting and re-creating the file.
      
      This fix should eliminate the possible double-free, the
      potential overflow and improve code readability.
      Signed-off-by: NMike Marshall <hubcap@omnibond.com>
      Signed-off-by: NMartin Brandenburg <martin@omnibond.com>
      dc033621
    • G
      openrisc: Define __ro_after_init to avoid crash · 2c7a5c5c
      Guenter Roeck 提交于
      openrisc qemu tests fail with the following crash.
      
      Unable to handle kernel access at virtual address 0xc0300c34
      
      Oops#: 0001
      CPU #: 0
         PC: c016c710    SR: 0000ae67    SP: c1017e04
         GPR00: 00000000 GPR01: c1017e04 GPR02: c0300c34 GPR03: c0300c34
         GPR04: 00000000 GPR05: c0300cb0 GPR06: c0300c34 GPR07: 000000ff
         GPR08: c107f074 GPR09: c0199ef4 GPR10: c1016000 GPR11: 00000000
         GPR12: 00000000 GPR13: c107f044 GPR14: c0473774 GPR15: 07ce0000
         GPR16: 00000000 GPR17: c107ed8a GPR18: 00009600 GPR19: c107f044
         GPR20: c107ee74 GPR21: 00000003 GPR22: c0473770 GPR23: 00000033
         GPR24: 000000bf GPR25: 00000019 GPR26: c046400c GPR27: 00000001
         GPR28: c0464028 GPR29: c1018000 GPR30: 00000006 GPR31: ccf37483
           RES: 00000000 oGPR11: ffffffff
           Process swapper (pid: 1, stackpage=c1001960)
      
           Stack: Stack dump [0xc1017cf8]:
           sp + 00: 0xc1017e04
           sp + 04: 0xc0300c34
           sp + 08: 0xc0300c34
           sp + 12: 0x00000000
      ...
      
      Bisect points to commit d2ec3f77 ("pty: make ptmx file ops read-only
      after init"). Fix by defining __ro_after_init for the openrisc
      architecture, similar to parisc.
      
      Fixes: d2ec3f77 ("pty: make ptmx file ops read-only after init")
      Cc: Kees Cook <keescook@chromium.org>
      Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
      Acked-by: NStafford Horne <shorne@gmail.com>
      2c7a5c5c
  6. 06 11月, 2016 12 次提交