1. 11 Nov, 2016 32 commits
    • Linus Torvalds's avatar
      Merge branch 'maybe-uninitialized' (patches from Arnd) · 015ed943
      Linus Torvalds authored
      Merge fixes for -Wmaybe-uninitialized from Arnd Bergmann:
       "It took a while for some patches to make it into mainline through
        maintainer trees, but the 28-patch series is now reduced to 10, with
        one tiny patch added at the end.
      
        Aside from patches that are no longer required, I did these changes
        compared to version 1:
      
         - Dropped "iio: maxim_thermocouple: detect invalid storage size in
           read()", which is currently in linux-next as commit 32cb7d27.
           This is the only remaining warning I see for a couple of corner
           cases (kbuild bot reports it on blackfin, kernelci bot and arm-soc
           bot both report it on arm64)
      
         - Dropped "brcmfmac: avoid maybe-uninitialized warning in
           brcmf_cfg80211_start_ap", which is currently in net/master merge
           pending.
      
         - Dropped two x86 patches, "x86: math-emu: possible uninitialized
           variable use" and "x86: mark target address as output in 'insb'
           asm" as they do not seem to trigger for a default build, and I got
           no feedback on them. Both of these are ancient issues and seem
           harmless, I will send them again to the x86 maintainers once the
           rest is merged.
      
         - Dropped "rbd: false-postive gcc-4.9 -Wmaybe-uninitialized" based on
           feedback from Ilya Dryomov, who already has a different fix queued
           up for v4.10. The kbuild bot reports this as a warning for xtensa.
      
         - Replaced "crypto: aesni: avoid -Wmaybe-uninitialized warning" with
           a simpler patch, this one always triggers but my first solution
           would not be safe for linux-4.9 any more at this point. I'll follow
           up with the larger patch as a cleanup for 4.10.
      
         - Replaced "dib0700: fix nec repeat handling" with a better one,
           contributed by Sean Young"
      
      * -Wmaybe-uninitialized fixes:
        Kbuild: enable -Wmaybe-uninitialized warnings by default
        pcmcia: fix return value of soc_pcmcia_regulator_set
        infiniband: shut up a maybe-uninitialized warning
        crypto: aesni: shut up -Wmaybe-uninitialized warning
        rc: print correct variable for z8f0811
        dib0700: fix nec repeat handling
        s390: pci: don't print uninitialized data for debugging
        nios2: fix timer initcall return value
        x86: apm: avoid uninitialized data
        NFSv4.1: work around -Wmaybe-uninitialized warning
        Kbuild: enable -Wmaybe-uninitialized warning for "make W=1"
      015ed943
    • Linus Torvalds's avatar
      Merge branch 'akpm' (patches from Andrew) · 968ef8de
      Linus Torvalds authored
      Merge misc fixes from Andrew Morton:
       "15 fixes"
      
      * emailed patches from Andrew Morton <akpm@linux-foundation.org>:
        lib/stackdepot: export save/fetch stack for drivers
        mm: kmemleak: scan .data.ro_after_init
        memcg: prevent memcg caches to be both OFF_SLAB & OBJFREELIST_SLAB
        coredump: fix unfreezable coredumping task
        mm/filemap: don't allow partially uptodate page for pipes
        mm/hugetlb: fix huge page reservation leak in private mapping error paths
        ocfs2: fix not enough credit panic
        Revert "console: don't prefer first registered if DT specifies stdout-path"
        mm: hwpoison: fix thp split handling in memory_failure()
        swapfile: fix memory corruption via malformed swapfile
        mm/cma.c: check the max limit for cma allocation
        scripts/bloat-o-meter: fix SIGPIPE
        shmem: fix pageflags after swapping DMA32 object
        mm, frontswap: make sure allocated frontswap map is assigned
        mm: remove extra newline from allocation stall warning
      968ef8de
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs · c5e4ca6d
      Linus Torvalds authored
      Pull VFS fixes from Al Viro:
       "Christoph's and Jan's aio fixes, fixup for generic_file_splice_read
        (removal of pointless detritus that actually breaks it when used for
        gfs2 ->splice_read()) and fixup for generic_file_read_iter()
        interaction with ITER_PIPE destinations."
      
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
        splice: remove detritus from generic_file_splice_read()
        mm/filemap: don't allow partially uptodate page for pipes
        aio: fix freeze protection of aio writes
        fs: remove aio_run_iocb
        fs: remove the never implemented aio_fsync file operation
        aio: hold an extra file reference over AIO read/write operations
      c5e4ca6d
    • Linus Torvalds's avatar
      Merge tag 'ceph-for-4.9-rc5' of git://github.com/ceph/ceph-client · ef091b3c
      Linus Torvalds authored
      Pull Ceph fixes from Ilya Dryomov:
       "Ceph's ->read_iter() implementation is incompatible with the new
        generic_file_splice_read() code that went into -rc1.  Switch to the
        less efficient default_file_splice_read() for now; the proper fix is
        being held for 4.10.
      
        We also have a fix for a 4.8 regression and a trival libceph fixup"
      
      * tag 'ceph-for-4.9-rc5' of git://github.com/ceph/ceph-client:
        libceph: initialize last_linger_id with a large integer
        libceph: fix legacy layout decode with pool 0
        ceph: use default file splice read callback
      ef091b3c
    • Linus Torvalds's avatar
      Merge tag 'nfs-for-4.9-3' of git://git.linux-nfs.org/projects/anna/linux-nfs · ef5beed9
      Linus Torvalds authored
      Pull NFS client bugfixes from Anna Schumaker:
       "Most of these fix regressions in 4.9, and none are going to stable
        this time around.
      
        Bugfixes:
         - Trim extra slashes in v4 nfs_paths to fix tools that use this
         - Fix a -Wmaybe-uninitialized warnings
         - Fix suspicious RCU usages
         - Fix Oops when mounting multiple servers at once
         - Suppress a false-positive pNFS error
         - Fix a DMAR failure in NFS over RDMA"
      
      * tag 'nfs-for-4.9-3' of git://git.linux-nfs.org/projects/anna/linux-nfs:
        xprtrdma: Fix DMAR failure in frwr_op_map() after reconnect
        fs/nfs: Fix used uninitialized warn in nfs4_slot_seqid_in_use()
        NFS: Don't print a pNFS error if we aren't using pNFS
        NFS: Ignore connections that have cl_rpcclient uninitialized
        SUNRPC: Fix suspicious RCU usage
        NFSv4.1: work around -Wmaybe-uninitialized warning
        NFS: Trim extra slash in v4 nfs_path
      ef5beed9
    • Linus Torvalds's avatar
      Merge tag 'xfs-fixes-for-linus-4.9-rc5' of... · a4fac3b5
      Linus Torvalds authored
      Merge tag 'xfs-fixes-for-linus-4.9-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/dgc/linux-xfs
      
      Pull xfs fix from Dave Chinner:
       "This is a fix for an unmount hang (regression) when the filesystem is
        shutdown.  It was supposed to go to you for -rc3, but I accidentally
        tagged the commit prior to it in that pullreq.
      
        Summary:
      
         - fix for aborting deferred transactions on filesystem shutdown"
      
      * tag 'xfs-fixes-for-linus-4.9-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/dgc/linux-xfs:
        xfs: defer should abort intent items if the trans roll fails
      a4fac3b5
    • Arnd Bergmann's avatar
      Kbuild: enable -Wmaybe-uninitialized warnings by default · 4324cb23
      Arnd Bergmann authored
      Previously the warnings were added back at the W=1 level and above, this
      now turns them on again by default, assuming that we have addressed all
      warnings and again have a clean build for v4.10.
      
      I found a number of new warnings in linux-next already and submitted
      bugfixes for those.  Hopefully they are caught by the 0day builder in
      the future as soon as this patch is merged.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      4324cb23
    • Arnd Bergmann's avatar
      pcmcia: fix return value of soc_pcmcia_regulator_set · 75ed2687
      Arnd Bergmann authored
      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: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      75ed2687
    • Arnd Bergmann's avatar
      infiniband: shut up a maybe-uninitialized warning · c50e90d0
      Arnd Bergmann authored
      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: default avatarHaggai Eran <haggaie@mellanox.com>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      c50e90d0
    • Arnd Bergmann's avatar
      crypto: aesni: shut up -Wmaybe-uninitialized warning · beae2c9e
      Arnd Bergmann authored
      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: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      beae2c9e
    • Arnd Bergmann's avatar
      rc: print correct variable for z8f0811 · 9cdbe14f
      Arnd Bergmann authored
      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: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      9cdbe14f
    • Sean Young's avatar
      dib0700: fix nec repeat handling · ba13e98f
      Sean Young authored
      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: default avatarSean Young <sean@mess.org>
      Tested-by: default avatarSean Young <sean@mess.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      ba13e98f
    • Arnd Bergmann's avatar
      s390: pci: don't print uninitialized data for debugging · 92dfffee
      Arnd Bergmann authored
      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: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarSebastian Ott <sebott@linux.vnet.ibm.com>
      Acked-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      92dfffee
    • Arnd Bergmann's avatar
      nios2: fix timer initcall return value · 069013a9
      Arnd Bergmann authored
      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: default avatarLey Foon Tan <lftan@altera.com>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      069013a9
    • Arnd Bergmann's avatar
      x86: apm: avoid uninitialized data · 3a6d8676
      Arnd Bergmann authored
      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: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarJiri Kosina <jkosina@suse.cz>
      Reviewed-by: default avatarLuis R. Rodriguez <mcgrof@kernel.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      3a6d8676
    • Arnd Bergmann's avatar
      NFSv4.1: work around -Wmaybe-uninitialized warning · e84efa32
      Arnd Bergmann authored
      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: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      e84efa32
    • Arnd Bergmann's avatar
      Kbuild: enable -Wmaybe-uninitialized warning for "make W=1" · a76bcf55
      Arnd Bergmann authored
      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: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a76bcf55
    • Chris Wilson's avatar
      lib/stackdepot: export save/fetch stack for drivers · ae65a21f
      Chris Wilson authored
      Some drivers would like to record stacktraces in order to aide leak
      tracing.  As stackdepot already provides a facility for only storing the
      unique traces, thereby reducing the memory required, export that
      functionality for use by drivers.
      
      The code was originally created for KASAN and moved under lib in commit
      cd11016e ("mm, kasan: stackdepot implementation.  Enable stackdepot
      for SLAB") so that it could be shared with mm/.  In turn, we want to
      share it now with drivers.
      
      Link: http://lkml.kernel.org/r/20161108133209.22704-1-chris@chris-wilson.co.ukSigned-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
      Cc: Alexander Potapenko <glider@google.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: "Kirill A. Shutemov" <kirill@shutemov.name>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      ae65a21f
    • Jakub Kicinski's avatar
      mm: kmemleak: scan .data.ro_after_init · d7c19b06
      Jakub Kicinski authored
      Limit the number of kmemleak false positives by including
      .data.ro_after_init in memory scanning.  To achieve this we need to add
      symbols for start and end of the section to the linker scripts.
      
      The problem was been uncovered by commit 56989f6d ("genetlink: mark
      families as __ro_after_init").
      
      Link: http://lkml.kernel.org/r/1478274173-15218-1-git-send-email-jakub.kicinski@netronome.comReviewed-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Cong Wang <xiyou.wangcong@gmail.com>
      Cc: Johannes Berg <johannes@sipsolutions.net>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      d7c19b06
    • Greg Thelen's avatar
      memcg: prevent memcg caches to be both OFF_SLAB & OBJFREELIST_SLAB · f773e36d
      Greg Thelen authored
      While testing OBJFREELIST_SLAB integration with pagealloc, we found a
      bug where kmem_cache(sys) would be created with both CFLGS_OFF_SLAB &
      CFLGS_OBJFREELIST_SLAB.  When it happened, critical allocations needed
      for loading drivers or creating new caches will fail.
      
      The original kmem_cache is created early making OFF_SLAB not possible.
      When kmem_cache(sys) is created, OFF_SLAB is possible and if pagealloc
      is enabled it will try to enable it first under certain conditions.
      Given kmem_cache(sys) reuses the original flag, you can have both flags
      at the same time resulting in allocation failures and odd behaviors.
      
      This fix discards allocator specific flags from memcg before calling
      create_cache.
      
      The bug exists since 4.6-rc1 and affects testing debug pagealloc
      configurations.
      
      Fixes: b03a017b ("mm/slab: introduce new slab management type, OBJFREELIST_SLAB")
      Link: http://lkml.kernel.org/r/1478553075-120242-1-git-send-email-thgarnie@google.comSigned-off-by: default avatarGreg Thelen <gthelen@google.com>
      Signed-off-by: default avatarThomas Garnier <thgarnie@google.com>
      Tested-by: default avatarThomas Garnier <thgarnie@google.com>
      Acked-by: default avatarChristoph Lameter <cl@linux.com>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
      Cc: Michal Hocko <mhocko@kernel.org>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      f773e36d
    • Andrey Ryabinin's avatar
      coredump: fix unfreezable coredumping task · 70d78fe7
      Andrey Ryabinin authored
      It could be not possible to freeze coredumping task when it waits for
      'core_state->startup' completion, because threads are frozen in
      get_signal() before they got a chance to complete 'core_state->startup'.
      
      Inability to freeze a task during suspend will cause suspend to fail.
      Also CRIU uses cgroup freezer during dump operation.  So with an
      unfreezable task the CRIU dump will fail because it waits for a
      transition from 'FREEZING' to 'FROZEN' state which will never happen.
      
      Use freezer_do_not_count() to tell freezer to ignore coredumping task
      while it waits for core_state->startup completion.
      
      Link: http://lkml.kernel.org/r/1475225434-3753-1-git-send-email-aryabinin@virtuozzo.comSigned-off-by: default avatarAndrey Ryabinin <aryabinin@virtuozzo.com>
      Acked-by: default avatarPavel Machek <pavel@ucw.cz>
      Acked-by: default avatarOleg Nesterov <oleg@redhat.com>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      Cc: Michal Hocko <mhocko@kernel.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      70d78fe7
    • Eryu Guan's avatar
      mm/filemap: don't allow partially uptodate page for pipes · 60da81ea
      Eryu Guan authored
      Starting from 4.9-rc1 kernel, I started noticing some test failures of
      sendfile(2) and splice(2) (sendfile0N and splice01 from LTP) when
      testing on sub-page block size filesystems (tested both XFS and ext4),
      these syscalls start to return EIO in the tests.  e.g.
      
        sendfile02    1  TFAIL  :  sendfile02.c:133: sendfile(2) failed to return expected value, expected: 26, got: -1
        sendfile02    2  TFAIL  :  sendfile02.c:133: sendfile(2) failed to return expected value, expected: 24, got: -1
        sendfile02    3  TFAIL  :  sendfile02.c:133: sendfile(2) failed to return expected value, expected: 22, got: -1
        sendfile02    4  TFAIL  :  sendfile02.c:133: sendfile(2) failed to return expected value, expected: 20, got: -1
      
      This is because that in sub-page block size cases, we don't need the
      whole page to be uptodate, only the part we care about is uptodate is OK
      (if fs has ->is_partially_uptodate defined).
      
      But page_cache_pipe_buf_confirm() doesn't have the ability to check the
      partially-uptodate case, it needs the whole page to be uptodate.  So it
      returns EIO in this case.
      
      This is a regression introduced by commit 82c156f8 ("switch
      generic_file_splice_read() to use of ->read_iter()").  Prior to the
      change, generic_file_splice_read() doesn't allow partially-uptodate page
      either, so it worked fine.
      
      Fix it by skipping the partially-uptodate check if we're working on a
      pipe in do_generic_file_read(), so we read the whole page from disk as
      long as the page is not uptodate.
      
      I think the other way to fix it is to add the ability to check & allow
      partially-uptodate page to page_cache_pipe_buf_confirm(), but that is
      much harder to do and seems gain little.
      
      Link: http://lkml.kernel.org/r/1477986187-12717-1-git-send-email-guaneryu@gmail.comSigned-off-by: default avatarEryu Guan <guaneryu@gmail.com>
      Reviewed-by: default avatarJan Kara <jack@suse.cz>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      60da81ea
    • Mike Kravetz's avatar
      mm/hugetlb: fix huge page reservation leak in private mapping error paths · 96b96a96
      Mike Kravetz authored
      Error paths in hugetlb_cow() and hugetlb_no_page() may free a newly
      allocated huge page.
      
      If a reservation was associated with the huge page, alloc_huge_page()
      consumed the reservation while allocating.  When the newly allocated
      page is freed in free_huge_page(), it will increment the global
      reservation count.  However, the reservation entry in the reserve map
      will remain.
      
      This is not an issue for shared mappings as the entry in the reserve map
      indicates a reservation exists.  But, an entry in a private mapping
      reserve map indicates the reservation was consumed and no longer exists.
      This results in an inconsistency between the reserve map and the global
      reservation count.  This 'leaks' a reserved huge page.
      
      Create a new routine restore_reserve_on_error() to restore the reserve
      entry in these specific error paths.  This routine makes use of a new
      function vma_add_reservation() which will add a reserve entry for a
      specific address/page.
      
      In general, these error paths were rarely (if ever) taken on most
      architectures.  However, powerpc contained arch specific code that that
      resulted in an extra fault and execution of these error paths on all
      private mappings.
      
      Fixes: 67961f9d ("mm/hugetlb: fix huge page reserve accounting for private mappings)
      Link: http://lkml.kernel.org/r/1476933077-23091-2-git-send-email-mike.kravetz@oracle.comSigned-off-by: default avatarMike Kravetz <mike.kravetz@oracle.com>
      Reported-by: default avatarJan Stancek <jstancek@redhat.com>
      Tested-by: default avatarJan Stancek <jstancek@redhat.com>
      Reviewed-by: default avatarAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Acked-by: default avatarHillf Danton <hillf.zj@alibaba-inc.com>
      Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Cc: Michal Hocko <mhocko@suse.com>
      Cc: Kirill A . Shutemov <kirill.shutemov@linux.intel.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      96b96a96
    • Junxiao Bi's avatar
      ocfs2: fix not enough credit panic · d006c71f
      Junxiao Bi authored
      The following panic was caught when run ocfs2 disconfig single test
      (block size 512 and cluster size 8192).  ocfs2_journal_dirty() return
      -ENOSPC, that means credits were used up.
      
      The total credit should include 3 times of "num_dx_leaves" from
      ocfs2_dx_dir_rebalance(), because 2 times will be consumed in
      ocfs2_dx_dir_transfer_leaf() and 1 time will be consumed in
      ocfs2_dx_dir_new_cluster() -> __ocfs2_dx_dir_new_cluster() ->
      ocfs2_dx_dir_format_cluster().  But only two times is included in
      ocfs2_dx_dir_rebalance_credits(), fix it.
      
      This can cause read-only fs(v4.1+) or panic for mainline linux depending
      on mount option.
      
        ------------[ cut here ]------------
        kernel BUG at fs/ocfs2/journal.c:775!
        invalid opcode: 0000 [#1] SMP
        Modules linked in: ocfs2 nfsd lockd grace nfs_acl auth_rpcgss sunrpc autofs4 ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue configfs sd_mod sg ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables be2iscsi iscsi_boot_sysfs bnx2i cnic uio cxgb4i cxgb4 cxgb3i libcxgbi cxgb3 mdio ib_iser rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr ipv6 iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ppdev xen_kbdfront xen_netfront fb_sys_fops sysimgblt sysfillrect syscopyarea parport_pc parport acpi_cpufreq i2c_piix4 i2c_core pcspkr ext4 jbd2 mbcache xen_blkfront floppy pata_acpi ata_generic ata_piix dm_mirror dm_region_hash dm_log dm_mod
        CPU: 2 PID: 10601 Comm: dd Not tainted 4.1.12-71.el6uek.bug24939243.x86_64 #2
        Hardware name: Xen HVM domU, BIOS 4.4.4OVM 02/11/2016
        task: ffff8800b6de6200 ti: ffff8800a7d48000 task.ti: ffff8800a7d48000
        RIP: ocfs2_journal_dirty+0xa7/0xb0 [ocfs2]
        RSP: 0018:ffff8800a7d4b6d8  EFLAGS: 00010286
        RAX: 00000000ffffffe4 RBX: 00000000814d0a9c RCX: 00000000000004f9
        RDX: ffffffffa008e990 RSI: ffffffffa008f1ee RDI: ffff8800622b6460
        RBP: ffff8800a7d4b6f8 R08: ffffffffa008f288 R09: ffff8800622b6460
        R10: 0000000000000000 R11: 0000000000000282 R12: 0000000002c8421e
        R13: ffff88006d0cad00 R14: ffff880092beef60 R15: 0000000000000070
        FS:  00007f9b83e92700(0000) GS:ffff8800be880000(0000) knlGS:0000000000000000
        CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
        CR2: 00007fb2c0d1a000 CR3: 0000000008f80000 CR4: 00000000000406e0
        Call Trace:
          ocfs2_dx_dir_transfer_leaf+0x159/0x1a0 [ocfs2]
          ocfs2_dx_dir_rebalance+0xd9b/0xea0 [ocfs2]
          ocfs2_find_dir_space_dx+0xd3/0x300 [ocfs2]
          ocfs2_prepare_dx_dir_for_insert+0x219/0x450 [ocfs2]
          ocfs2_prepare_dir_for_insert+0x1d6/0x580 [ocfs2]
          ocfs2_mknod+0x5a2/0x1400 [ocfs2]
          ocfs2_create+0x73/0x180 [ocfs2]
          vfs_create+0xd8/0x100
          lookup_open+0x185/0x1c0
          do_last+0x36d/0x780
          path_openat+0x92/0x470
          do_filp_open+0x4a/0xa0
          do_sys_open+0x11a/0x230
          SyS_open+0x1e/0x20
          system_call_fastpath+0x12/0x71
        Code: 1d 3f 29 09 00 48 85 db 74 1f 48 8b 03 0f 1f 80 00 00 00 00 48 8b 7b 08 48 83 c3 10 4c 89 e6 ff d0 48 8b 03 48 85 c0 75 eb eb 90 <0f> 0b eb fe 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 55 41 54
        RIP  ocfs2_journal_dirty+0xa7/0xb0 [ocfs2]
        ---[ end trace 91ac5312a6ee1288 ]---
        Kernel panic - not syncing: Fatal exception
        Kernel Offset: disabled
      
      Link: http://lkml.kernel.org/r/1478248135-31963-1-git-send-email-junxiao.bi@oracle.comSigned-off-by: default avatarJunxiao Bi <junxiao.bi@oracle.com>
      Cc: Mark Fasheh <mfasheh@versity.com>
      Cc: Joel Becker <jlbec@evilplan.org>
      Cc: Joseph Qi <joseph.qi@huawei.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      d006c71f
    • Hans de Goede's avatar
      Revert "console: don't prefer first registered if DT specifies stdout-path" · c6c7d83b
      Hans de Goede authored
      This reverts commit 05fd007e ("console: don't prefer first
      registered if DT specifies stdout-path").
      
      The reverted commit changes existing behavior on which many ARM boards
      rely.  Many ARM small-board-computers, like e.g.  the Raspberry Pi have
      both a video output and a serial console.  Depending on whether the user
      is using the device as a more regular computer; or as a headless device
      we need to have the console on either one or the other.
      
      Many users rely on the kernel behavior of the console being present on
      both outputs, before the reverted commit the console setup with no
      console= kernel arguments on an ARM board which sets stdout-path in dt
      would look like this:
      
        [root@localhost ~]# cat /proc/consoles
        ttyS0                -W- (EC p a)    4:64
        tty0                 -WU (E  p  )    4:1
      
      Where as after the reverted commit, it looks like this:
      
        [root@localhost ~]# cat /proc/consoles
        ttyS0                -W- (EC p a)    4:64
      
      This commit reverts commit 05fd007e ("console: don't prefer first
      registered if DT specifies stdout-path") restoring the original
      behavior.
      
      Fixes: 05fd007e ("console: don't prefer first registered if DT specifies stdout-path")
      Link: http://lkml.kernel.org/r/20161104121135.4780-2-hdegoede@redhat.comSigned-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: Rob Herring <robh+dt@kernel.org>
      Cc: Frank Rowand <frowand.list@gmail.com>
      Cc: Thorsten Leemhuis <regressions@leemhuis.info>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      c6c7d83b
    • Naoya Horiguchi's avatar
      mm: hwpoison: fix thp split handling in memory_failure() · c3901e72
      Naoya Horiguchi authored
      When memory_failure() runs on a thp tail page after pmd is split, we
      trigger the following VM_BUG_ON_PAGE():
      
         page:ffffd7cd819b0040 count:0 mapcount:0 mapping:         (null) index:0x1
         flags: 0x1fffc000400000(hwpoison)
         page dumped because: VM_BUG_ON_PAGE(!page_count(p))
         ------------[ cut here ]------------
         kernel BUG at /src/linux-dev/mm/memory-failure.c:1132!
      
      memory_failure() passed refcount and page lock from tail page to head
      page, which is not needed because we can pass any subpage to
      split_huge_page().
      
      Fixes: 61f5d698 ("mm: re-enable THP")
      Link: http://lkml.kernel.org/r/1477961577-7183-1-git-send-email-n-horiguchi@ah.jp.nec.comSigned-off-by: default avatarNaoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Cc: <stable@vger.kernel.org>	[4.5+]
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      c3901e72
    • Jann Horn's avatar
      swapfile: fix memory corruption via malformed swapfile · dd111be6
      Jann Horn authored
      When root activates a swap partition whose header has the wrong
      endianness, nr_badpages elements of badpages are swabbed before
      nr_badpages has been checked, leading to a buffer overrun of up to 8GB.
      
      This normally is not a security issue because it can only be exploited
      by root (more specifically, a process with CAP_SYS_ADMIN or the ability
      to modify a swap file/partition), and such a process can already e.g.
      modify swapped-out memory of any other userspace process on the system.
      
      Link: http://lkml.kernel.org/r/1477949533-2509-1-git-send-email-jann@thejh.netSigned-off-by: default avatarJann Horn <jann@thejh.net>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      Acked-by: default avatarJerome Marchand <jmarchan@redhat.com>
      Acked-by: default avatarJohannes Weiner <hannes@cmpxchg.org>
      Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      dd111be6
    • Shiraz Hashim's avatar
      mm/cma.c: check the max limit for cma allocation · 6b36ba59
      Shiraz Hashim authored
      CMA allocation request size is represented by size_t that gets truncated
      when same is passed as int to bitmap_find_next_zero_area_off.
      
      We observe that during fuzz testing when cma allocation request is too
      high, bitmap_find_next_zero_area_off still returns success due to the
      truncation.  This leads to kernel crash, as subsequent code assumes that
      requested memory is available.
      
      Fail cma allocation in case the request breaches the corresponding cma
      region size.
      
      Link: http://lkml.kernel.org/r/1478189211-3467-1-git-send-email-shashim@codeaurora.orgSigned-off-by: default avatarShiraz Hashim <shashim@codeaurora.org>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      6b36ba59
    • Alexey Dobriyan's avatar
      scripts/bloat-o-meter: fix SIGPIPE · eef06b82
      Alexey Dobriyan authored
      Fix piping output to a program which quickly exits (read: head -n1)
      
      	$ ./scripts/bloat-o-meter ../vmlinux-000 ../obj/vmlinux | head -n1
      	add/remove: 0/0 grow/shrink: 9/60 up/down: 124/-305 (-181)
      	close failed in file object destructor:
      	sys.excepthook is missing
      	lost sys.stderr
      
      Link: http://lkml.kernel.org/r/20161028204618.GA29923@avx2Signed-off-by: default avatarAlexey Dobriyan <adobriyan@gmail.com>
      Cc: Matt Mackall <mpm@selenic.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      eef06b82
    • Hugh Dickins's avatar
      shmem: fix pageflags after swapping DMA32 object · 9956edf3
      Hugh Dickins authored
      If shmem_alloc_page() does not set PageLocked and PageSwapBacked, then
      shmem_replace_page() needs to do so for itself.  Without this, it puts
      newpage on the wrong lru, re-unlocks the unlocked newpage, and system
      descends into "Bad page" reports and freeze; or if CONFIG_DEBUG_VM=y, it
      hits an earlier VM_BUG_ON_PAGE(!PageLocked), depending on config.
      
      But shmem_replace_page() is not a common path: it's only called when
      swapin (or swapoff) finds the page was already read into an unsuitable
      zone: usually all zones are suitable, but gem objects for a few drm
      devices (gma500, omapdrm, crestline, broadwater) require zone DMA32 if
      there's more than 4GB of ram.
      
      Fixes: 800d8c63 ("shmem: add huge pages support")
      Link: http://lkml.kernel.org/r/alpine.LSU.2.11.1611062003510.11253@eggly.anvilsSigned-off-by: default avatarHugh Dickins <hughd@google.com>
      Acked-by: default avatarKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Cc: <stable@vger.kernel.org>	[4.8.x]
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      9956edf3
    • Vlastimil Babka's avatar
      mm, frontswap: make sure allocated frontswap map is assigned · 5e322bee
      Vlastimil Babka authored
      Christian Borntraeger reports:
      
      With commit 8ea1d2a1 ("mm, frontswap: convert frontswap_enabled to
      static key") kmemleak complains about a memory leak in swapon
      
          unreferenced object 0x3e09ba56000 (size 32112640):
            comm "swapon", pid 7852, jiffies 4294968787 (age 1490.770s)
            hex dump (first 32 bytes):
              00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
              00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
            backtrace:
               __vmalloc_node_range+0x194/0x2d8
               vzalloc+0x58/0x68
               SyS_swapon+0xd60/0x12f8
               system_call+0xd6/0x270
      
      Turns out kmemleak is right.  We now allocate the frontswap map
      depending on the kernel config (and no longer on the enablement)
      
        swapfile.c:
        [...]
            if (IS_ENABLED(CONFIG_FRONTSWAP))
                      frontswap_map = vzalloc(BITS_TO_LONGS(maxpages) * sizeof(long));
      
      but later on this is passed along
        --> enable_swap_info(p, prio, swap_map, cluster_info, frontswap_map);
      
      and ignored if frontswap is disabled
        --> frontswap_init(p->type, frontswap_map);
      
        static inline void frontswap_init(unsigned type, unsigned long *map)
        {
              if (frontswap_enabled())
                      __frontswap_init(type, map);
        }
      
      Thing is, that frontswap map is never freed.
      
      The leakage is relatively not that bad, because swapon is an infrequent
      and privileged operation.  However, if the first frontswap backend is
      registered after a swap type has been already enabled, it will WARN_ON
      in frontswap_register_ops() and frontswap will not be available for the
      swap type.
      
      Fix this by making sure the map is assigned by frontswap_init() as long
      as CONFIG_FRONTSWAP is enabled.
      
      Fixes: 8ea1d2a1 ("mm, frontswap: convert frontswap_enabled to static key")
      Link: http://lkml.kernel.org/r/20161026134220.2566-1-vbabka@suse.czSigned-off-by: default avatarVlastimil Babka <vbabka@suse.cz>
      Reported-by: default avatarChristian Borntraeger <borntraeger@de.ibm.com>
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: David Vrabel <david.vrabel@citrix.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      5e322bee
    • Tetsuo Handa's avatar
      mm: remove extra newline from allocation stall warning · 9e80c719
      Tetsuo Handa authored
      Commit 63f53dea ("mm: warn about allocations which stall for too
      long") by error embedded "\n" in the format string, resulting in strange
      output.
      
        [  722.876655] kworker/0:1: page alloction stalls for 160001ms, order:0
        [  722.876656] , mode:0x2400000(GFP_NOIO)
        [  722.876657] CPU: 0 PID: 6966 Comm: kworker/0:1 Not tainted 4.8.0+ #69
      
      Link: http://lkml.kernel.org/r/1476026219-7974-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jpSigned-off-by: default avatarTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      9e80c719
  2. 10 Nov, 2016 5 commits
  3. 09 Nov, 2016 3 commits
    • Linus Torvalds's avatar
      Merge tag 'sound-4.9-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound · 27bcd37e
      Linus Torvalds authored
      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
    • Linus Torvalds's avatar
      Merge tag 'for-linus-4.9-rc4-ofs-1' of git://git.kernel.org/pub/scm/linux/kernel/git/hubcap/linux · 3c6106da
      Linus Torvalds authored
      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
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux · ae67e87f
      Linus Torvalds authored
      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