1. 26 Aug, 2017 40 commits
    • Mark Rutland's avatar
      arm64: uaccess: ensure extension of access_ok() addr · 42b124b5
      Mark Rutland authored
      commit a06040d7 upstream.
      
      Our access_ok() simply hands its arguments over to __range_ok(), which
      implicitly assummes that the addr parameter is 64 bits wide. This isn't
      necessarily true for compat code, which might pass down a 32-bit address
      parameter.
      
      In these cases, we don't have a guarantee that the address has been zero
      extended to 64 bits, and the upper bits of the register may contain
      unknown values, potentially resulting in a suprious failure.
      
      Avoid this by explicitly casting the addr parameter to an unsigned long
      (as is done on other architectures), ensuring that the parameter is
      widened appropriately.
      
      Fixes: 0aea86a2 ("arm64: User access library functions")
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      42b124b5
    • Mark Rutland's avatar
      arm64: ensure extension of smp_store_release value · 3f58c533
      Mark Rutland authored
      commit 994870be upstream.
      
      When an inline assembly operand's type is narrower than the register it
      is allocated to, the least significant bits of the register (up to the
      operand type's width) are valid, and any other bits are permitted to
      contain any arbitrary value. This aligns with the AAPCS64 parameter
      passing rules.
      
      Our __smp_store_release() implementation does not account for this, and
      implicitly assumes that operands have been zero-extended to the width of
      the type being stored to. Thus, we may store unknown values to memory
      when the value type is narrower than the pointer type (e.g. when storing
      a char to a long).
      
      This patch fixes the issue by casting the value operand to the same
      width as the pointer operand in all cases, which ensures that the value
      is zero-extended as we expect. We use the same union trickery as
      __smp_load_acquire and {READ,WRITE}_ONCE() to avoid GCC complaining that
      pointers are potentially cast to narrower width integers in unreachable
      paths.
      
      A whitespace issue at the top of __smp_store_release() is also
      corrected.
      
      No changes are necessary for __smp_load_acquire(). Load instructions
      implicitly clear any upper bits of the register, and the compiler will
      only consider the least significant bits of the register as valid
      regardless.
      
      Fixes: 47933ad4 ("arch: Introduce smp_load_acquire(), smp_store_release()")
      Fixes: 878a84d5 ("arm64: add missing data types in smp_load_acquire/smp_store_release")
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Cc: Matthias Kaehlcke <mka@chromium.org>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      [bwh: Backported to 3.16: smp_store_release() only supports 32- and 64-bit
       types]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      3f58c533
    • Talat Batheesh's avatar
      net/mlx4_en: Avoid adding steering rules with invalid ring · f1666123
      Talat Batheesh authored
      commit 89c55768 upstream.
      
      Inserting steering rules with illegal ring is an invalid operation,
      block it.
      
      Fixes: 82067281 ('net/mlx4_en: Manage flow steering rules with ethtool')
      Signed-off-by: default avatarTalat Batheesh <talatb@mellanox.com>
      Signed-off-by: default avatarTariq Toukan <tariqt@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      f1666123
    • Kamal Heib's avatar
      net/mlx4_en: Change the error print to debug print · 7faa1486
      Kamal Heib authored
      commit 505a9249 upstream.
      
      The error print within mlx4_en_calc_rx_buf() should be a debug print.
      
      Fixes: 51151a16 ('mlx4: allow order-0 memory allocations in RX path')
      Signed-off-by: default avatarKamal Heib <kamalh@mellanox.com>
      Signed-off-by: default avatarTariq Toukan <tariqt@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [bwh: Backported to 3.16: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      7faa1486
    • Michael S. Tsirkin's avatar
      virtio_net: fix support for small rings · 793d7770
      Michael S. Tsirkin authored
      commit d85b758f upstream.
      
      When ring size is small (<32 entries) making buffers smaller means a
      full ring might not be able to hold enough buffers to fit a single large
      packet.
      
      Make sure a ring full of buffers is large enough to allow at least one
      packet of max size.
      
      Fixes: 2613af0e ("virtio_net: migrate mergeable rx buffers to page frag allocators")
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      [bwh: Backported to 3.16:
       - There's no net_device::max_mtu, so always set packet_len = IP_MAX_MTU
       - Adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      793d7770
    • Laura Abbott's avatar
      x86/mm/32: Set the '__vmalloc_start_set' flag in initmem_init() · ef137606
      Laura Abbott authored
      commit 861ce4a3 upstream.
      
      '__vmalloc_start_set' currently only gets set in initmem_init() when
      !CONFIG_NEED_MULTIPLE_NODES. This breaks detection of vmalloc address
      with virt_addr_valid() with CONFIG_NEED_MULTIPLE_NODES=y, causing
      a kernel crash:
      
        [mm/usercopy] 517e1fbe: kernel BUG at arch/x86/mm/physaddr.c:78!
      
      Set '__vmalloc_start_set' appropriately for that case as well.
      Reported-by: default avatarkbuild test robot <fengguang.wu@intel.com>
      Signed-off-by: default avatarLaura Abbott <labbott@redhat.com>
      Reviewed-by: default avatarKees Cook <keescook@chromium.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Fixes: dc16ecf7 ("x86-32: use specific __vmalloc_start_set flag in __virt_addr_valid")
      Link: http://lkml.kernel.org/r/1494278596-30373-1-git-send-email-labbott@redhat.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      ef137606
    • Michal Hocko's avatar
      fs/xattr.c: zero out memory copied to userspace in getxattr · 0dc00866
      Michal Hocko authored
      commit 81be3dee upstream.
      
      getxattr uses vmalloc to allocate memory if kzalloc fails.  This is
      filled by vfs_getxattr and then copied to the userspace.  vmalloc,
      however, doesn't zero out the memory so if the specific implementation
      of the xattr handler is sloppy we can theoretically expose a kernel
      memory.  There is no real sign this is really the case but let's make
      sure this will not happen and use vzalloc instead.
      
      Fixes: 779302e6 ("fs/xattr.c:getxattr(): improve handling of allocation failures")
      Link: http://lkml.kernel.org/r/20170306103327.2766-1-mhocko@kernel.orgAcked-by: default avatarKees Cook <keescook@chromium.org>
      Reported-by: default avatarVlastimil Babka <vbabka@suse.cz>
      Signed-off-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>
      [bwh: Backported to 3.16: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      0dc00866
    • Bart Van Assche's avatar
      target/fileio: Fix zero-length READ and WRITE handling · 988a86df
      Bart Van Assche authored
      commit 59ac9c07 upstream.
      
      This patch fixes zero-length READ and WRITE handling in target/FILEIO,
      which was broken a long time back by:
      
      Since:
      
        commit d81cb447
        Author: Paolo Bonzini <pbonzini@redhat.com>
        Date:   Mon Sep 17 16:36:11 2012 -0700
      
            target: go through normal processing for all zero-length commands
      
      which moved zero-length READ and WRITE completion out of target-core,
      to doing submission into backend driver code.
      
      To address this, go ahead and invoke target_complete_cmd() for any
      non negative return value in fd_do_rw().
      Signed-off-by: default avatarBart Van Assche <bart.vanassche@sandisk.com>
      Reviewed-by: default avatarHannes Reinecke <hare@suse.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Cc: Andy Grover <agrover@redhat.com>
      Cc: David Disseldorp <ddiss@suse.de>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      988a86df
    • Arnd Bergmann's avatar
      fbdev: sti: don't select CONFIG_VT · f28f6f2e
      Arnd Bergmann authored
      commit 34bf129a upstream.
      
      While working on another build error, I ran into several variations of
      this dependency loop:
      
      subsection "Kconfig recursive dependency limitations"
      drivers/input/Kconfig:8:	symbol INPUT is selected by VT
      For a resolution refer to Documentation/kbuild/kconfig-language.txt
      subsection "Kconfig recursive dependency limitations"
      drivers/tty/Kconfig:12:	symbol VT is selected by FB_STI
      For a resolution refer to Documentation/kbuild/kconfig-language.txt
      subsection "Kconfig recursive dependency limitations"
      drivers/video/fbdev/Kconfig:677:	symbol FB_STI depends on FB
      For a resolution refer to Documentation/kbuild/kconfig-language.txt
      subsection "Kconfig recursive dependency limitations"
      drivers/video/fbdev/Kconfig:5:	symbol FB is selected by DRM_KMS_FB_HELPER
      For a resolution refer to Documentation/kbuild/kconfig-language.txt
      subsection "Kconfig recursive dependency limitations"
      drivers/gpu/drm/Kconfig:72:	symbol DRM_KMS_FB_HELPER is selected by DRM_KMS_CMA_HELPER
      For a resolution refer to Documentation/kbuild/kconfig-language.txt
      subsection "Kconfig recursive dependency limitations"
      drivers/gpu/drm/Kconfig:137:	symbol DRM_KMS_CMA_HELPER is selected by DRM_HDLCD
      For a resolution refer to Documentation/kbuild/kconfig-language.txt
      subsection "Kconfig recursive dependency limitations"
      drivers/gpu/drm/arm/Kconfig:6:	symbol DRM_HDLCD depends on OF
      For a resolution refer to Documentation/kbuild/kconfig-language.txt
      subsection "Kconfig recursive dependency limitations"
      drivers/of/Kconfig:4:	symbol OF is selected by X86_INTEL_CE
      For a resolution refer to Documentation/kbuild/kconfig-language.txt
      subsection "Kconfig recursive dependency limitations"
      arch/x86/Kconfig:523:	symbol X86_INTEL_CE depends on X86_IO_APIC
      For a resolution refer to Documentation/kbuild/kconfig-language.txt
      subsection "Kconfig recursive dependency limitations"
      arch/x86/Kconfig:1011:	symbol X86_IO_APIC depends on X86_LOCAL_APIC
      For a resolution refer to Documentation/kbuild/kconfig-language.txt
      subsection "Kconfig recursive dependency limitations"
      arch/x86/Kconfig:1005:	symbol X86_LOCAL_APIC depends on X86_UP_APIC
      For a resolution refer to Documentation/kbuild/kconfig-language.txt
      subsection "Kconfig recursive dependency limitations"
      arch/x86/Kconfig:980:	symbol X86_UP_APIC depends on PCI_MSI
      For a resolution refer to Documentation/kbuild/kconfig-language.txt
      subsection "Kconfig recursive dependency limitations"
      drivers/pci/Kconfig:11:	symbol PCI_MSI is selected by AMD_IOMMU
      For a resolution refer to Documentation/kbuild/kconfig-language.txt
      subsection "Kconfig recursive dependency limitations"
      drivers/iommu/Kconfig:106:	symbol AMD_IOMMU depends on IOMMU_SUPPORT
      For a resolution refer to Documentation/kbuild/kconfig-language.txt
      subsection "Kconfig recursive dependency limitations"
      drivers/iommu/Kconfig:5:	symbol IOMMU_SUPPORT is selected by DRM_ETNAVIV
      For a resolution refer to Documentation/kbuild/kconfig-language.txt
      subsection "Kconfig recursive dependency limitations"
      drivers/gpu/drm/etnaviv/Kconfig:2:	symbol DRM_ETNAVIV depends on THERMAL
      For a resolution refer to Documentation/kbuild/kconfig-language.txt
      subsection "Kconfig recursive dependency limitations"
      drivers/thermal/Kconfig:5:	symbol THERMAL is selected by ACPI_VIDEO
      For a resolution refer to Documentation/kbuild/kconfig-language.txt
      subsection "Kconfig recursive dependency limitations"
      drivers/acpi/Kconfig:183:	symbol ACPI_VIDEO is selected by INPUT
      
      This doesn't currently show up as I fixed the 'THERMAL' part of it,
      but I noticed that the FB_STI dependency should not be there but
      was introduced by slightly incorrect bug-fix patch that tried to
      fix a link error.
      
      Instead of selecting 'VT' to make us enter the drivers/video/console
      directory at compile-time, it's sufficient to build the
      drivers/video/console/sticore.c file by adding its directory
      to when CONFIG_FB_STI is enabled. Alternatively, we could move the
      sticore code to another directory that is always built when we
      have at STI_CONSOLE or FB_STI enabled.
      
      Fixes: 17085a93 ("parisc: stifb: should depend on STI_CONSOLE")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Cc: Helge Deller <deller@gmx.de>
      Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
      Cc: Alexander Beregalov <a.beregalov@gmail.com>
      Signed-off-by: default avatarBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      f28f6f2e
    • Rob Herring's avatar
      of: fix sparse warning in of_pci_range_parser_one · 6d1231a8
      Rob Herring authored
      commit eb310036 upstream.
      
      sparse gives the following warning for 'pci_space':
      
      ../drivers/of/address.c:266:26: warning: incorrect type in assignment (different base types)
      ../drivers/of/address.c:266:26:    expected unsigned int [unsigned] [usertype] pci_space
      ../drivers/of/address.c:266:26:    got restricted __be32 const [usertype] <noident>
      
      It appears that pci_space is only ever accessed on powerpc, so the endian
      swap is often not needed.
      Signed-off-by: default avatarRob Herring <robh@kernel.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      6d1231a8
    • Luis Henriques's avatar
      ceph: fix memory leak in __ceph_setxattr() · 3c42d664
      Luis Henriques authored
      commit eeca958d upstream.
      
      The ceph_inode_xattr needs to be released when removing an xattr.  Easily
      reproducible running the 'generic/020' test from xfstests or simply by
      doing:
      
        attr -s attr0 -V 0 /mnt/test && attr -r attr0 /mnt/test
      
      While there, also fix the error path.
      
      Here's the kmemleak splat:
      
      unreferenced object 0xffff88001f86fbc0 (size 64):
        comm "attr", pid 244, jiffies 4294904246 (age 98.464s)
        hex dump (first 32 bytes):
          40 fa 86 1f 00 88 ff ff 80 32 38 1f 00 88 ff ff  @........28.....
          00 01 00 00 00 00 ad de 00 02 00 00 00 00 ad de  ................
        backtrace:
          [<ffffffff81560199>] kmemleak_alloc+0x49/0xa0
          [<ffffffff810f3e5b>] kmem_cache_alloc+0x9b/0xf0
          [<ffffffff812b157e>] __ceph_setxattr+0x17e/0x820
          [<ffffffff812b1c57>] ceph_set_xattr_handler+0x37/0x40
          [<ffffffff8111fb4b>] __vfs_removexattr+0x4b/0x60
          [<ffffffff8111fd37>] vfs_removexattr+0x77/0xd0
          [<ffffffff8111fdd1>] removexattr+0x41/0x60
          [<ffffffff8111fe65>] path_removexattr+0x75/0xa0
          [<ffffffff81120aeb>] SyS_lremovexattr+0xb/0x10
          [<ffffffff81564b20>] entry_SYSCALL_64_fastpath+0x13/0x94
          [<ffffffffffffffff>] 0xffffffffffffffff
      Signed-off-by: default avatarLuis Henriques <lhenriques@suse.com>
      Reviewed-by: default avatar"Yan, Zheng" <zyan@redhat.com>
      Signed-off-by: default avatarIlya Dryomov <idryomov@gmail.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      3c42d664
    • Steve French's avatar
      SMB3: Work around mount failure when using SMB3 dialect to Macs · 0dd752f9
      Steve French authored
      commit 7db0a6ef upstream.
      
      Macs send the maximum buffer size in response on ioctl to validate
      negotiate security information, which causes us to fail the mount
      as the response buffer is larger than the expected response.
      
      Changed ioctl response processing to allow for padding of validate
      negotiate ioctl response and limit the maximum response size to
      maximum buffer size.
      Signed-off-by: default avatarSteve French <steve.french@primarydata.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      0dd752f9
    • Nikolay Borisov's avatar
      lockdep: teach lockdep about memalloc_noio_save · b28ebfc0
      Nikolay Borisov authored
      commit 6d7225f0 upstream.
      
      Patch series "scope GFP_NOFS api", v5.
      
      This patch (of 7):
      
      Commit 21caf2fc ("mm: teach mm by current context info to not do I/O
      during memory allocation") added the memalloc_noio_(save|restore)
      functions to enable people to modify the MM behavior by disabling I/O
      during memory allocation.
      
      This was further extended in commit 934f3072 ("mm: clear __GFP_FS
      when PF_MEMALLOC_NOIO is set").
      
      memalloc_noio_* functions prevent allocation paths recursing back into
      the filesystem without explicitly changing the flags for every
      allocation site.
      
      However, lockdep hasn't been keeping up with the changes and it entirely
      misses handling the memalloc_noio adjustments.  Instead, it is left to
      the callers of __lockdep_trace_alloc to call the function after they
      have shaven the respective GFP flags which can lead to false positives:
      
        =================================
         [ INFO: inconsistent lock state ]
         4.10.0-nbor #134 Not tainted
         ---------------------------------
         inconsistent {IN-RECLAIM_FS-W} -> {RECLAIM_FS-ON-W} usage.
         fsstress/3365 [HC0[0]:SC0[0]:HE1:SE1] takes:
          (&xfs_nondir_ilock_class){++++?.}, at: xfs_ilock+0x141/0x230
         {IN-RECLAIM_FS-W} state was registered at:
           __lock_acquire+0x62a/0x17c0
           lock_acquire+0xc5/0x220
           down_write_nested+0x4f/0x90
           xfs_ilock+0x141/0x230
           xfs_reclaim_inode+0x12a/0x320
           xfs_reclaim_inodes_ag+0x2c8/0x4e0
           xfs_reclaim_inodes_nr+0x33/0x40
           xfs_fs_free_cached_objects+0x19/0x20
           super_cache_scan+0x191/0x1a0
           shrink_slab+0x26f/0x5f0
           shrink_node+0xf9/0x2f0
           kswapd+0x356/0x920
           kthread+0x10c/0x140
           ret_from_fork+0x31/0x40
         irq event stamp: 173777
         hardirqs last  enabled at (173777): __local_bh_enable_ip+0x70/0xc0
         hardirqs last disabled at (173775): __local_bh_enable_ip+0x37/0xc0
         softirqs last  enabled at (173776): _xfs_buf_find+0x67a/0xb70
         softirqs last disabled at (173774): _xfs_buf_find+0x5db/0xb70
      
         other info that might help us debug this:
          Possible unsafe locking scenario:
      
                CPU0
                ----
           lock(&xfs_nondir_ilock_class);
           <Interrupt>
             lock(&xfs_nondir_ilock_class);
      
          *** DEADLOCK ***
      
         4 locks held by fsstress/3365:
          #0:  (sb_writers#10){++++++}, at: mnt_want_write+0x24/0x50
          #1:  (&sb->s_type->i_mutex_key#12){++++++}, at: vfs_setxattr+0x6f/0xb0
          #2:  (sb_internal#2){++++++}, at: xfs_trans_alloc+0xfc/0x140
          #3:  (&xfs_nondir_ilock_class){++++?.}, at: xfs_ilock+0x141/0x230
      
         stack backtrace:
         CPU: 0 PID: 3365 Comm: fsstress Not tainted 4.10.0-nbor #134
         Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
         Call Trace:
          kmem_cache_alloc_node_trace+0x3a/0x2c0
          vm_map_ram+0x2a1/0x510
          _xfs_buf_map_pages+0x77/0x140
          xfs_buf_get_map+0x185/0x2a0
          xfs_attr_rmtval_set+0x233/0x430
          xfs_attr_leaf_addname+0x2d2/0x500
          xfs_attr_set+0x214/0x420
          xfs_xattr_set+0x59/0xb0
          __vfs_setxattr+0x76/0xa0
          __vfs_setxattr_noperm+0x5e/0xf0
          vfs_setxattr+0xae/0xb0
          setxattr+0x15e/0x1a0
          path_setxattr+0x8f/0xc0
          SyS_lsetxattr+0x11/0x20
          entry_SYSCALL_64_fastpath+0x23/0xc6
      
      Let's fix this by making lockdep explicitly do the shaving of respective
      GFP flags.
      
      Fixes: 934f3072 ("mm: clear __GFP_FS when PF_MEMALLOC_NOIO is set")
      Link: http://lkml.kernel.org/r/20170306131408.9828-2-mhocko@kernel.orgSigned-off-by: default avatarNikolay Borisov <nborisov@suse.com>
      Signed-off-by: default avatarMichal Hocko <mhocko@suse.com>
      Acked-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Dave Chinner <david@fromorbit.com>
      Cc: Theodore Ts'o <tytso@mit.edu>
      Cc: Chris Mason <clm@fb.com>
      Cc: David Sterba <dsterba@suse.cz>
      Cc: Jan Kara <jack@suse.cz>
      Cc: Brian Foster <bfoster@redhat.com>
      Cc: Darrick J. Wong <darrick.wong@oracle.com>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      [bwh: Backported to 3.16: no need to touch #includes]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      b28ebfc0
    • Richard Weinberger's avatar
      um: Fix PTRACE_POKEUSER on x86_64 · 0d669d90
      Richard Weinberger authored
      commit 9abc74a2 upstream.
      
      This is broken since ever but sadly nobody noticed.
      Recent versions of GDB set DR_CONTROL unconditionally and
      UML dies due to a heap corruption. It turns out that
      the PTRACE_POKEUSER was copy&pasted from i386 and assumes
      that addresses are 4 bytes long.
      
      Fix that by using 8 as address size in the calculation.
      Reported-by: default avatarjie cao <cj3054@gmail.com>
      Signed-off-by: default avatarRichard Weinberger <richard@nod.at>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      0d669d90
    • Rabin Vincent's avatar
      CIFS: fix oplock break deadlocks · 2080cbfa
      Rabin Vincent authored
      commit 3998e6b8 upstream.
      
      When the final cifsFileInfo_put() is called from cifsiod and an oplock
      break work is queued, lockdep complains loudly:
      
       =============================================
       [ INFO: possible recursive locking detected ]
       4.11.0+ #21 Not tainted
       ---------------------------------------------
       kworker/0:2/78 is trying to acquire lock:
        ("cifsiod"){++++.+}, at: flush_work+0x215/0x350
      
       but task is already holding lock:
        ("cifsiod"){++++.+}, at: process_one_work+0x255/0x8e0
      
       other info that might help us debug this:
        Possible unsafe locking scenario:
      
              CPU0
              ----
         lock("cifsiod");
         lock("cifsiod");
      
        *** DEADLOCK ***
      
        May be due to missing lock nesting notation
      
       2 locks held by kworker/0:2/78:
        #0:  ("cifsiod"){++++.+}, at: process_one_work+0x255/0x8e0
        #1:  ((&wdata->work)){+.+...}, at: process_one_work+0x255/0x8e0
      
       stack backtrace:
       CPU: 0 PID: 78 Comm: kworker/0:2 Not tainted 4.11.0+ #21
       Workqueue: cifsiod cifs_writev_complete
       Call Trace:
        dump_stack+0x85/0xc2
        __lock_acquire+0x17dd/0x2260
        ? match_held_lock+0x20/0x2b0
        ? trace_hardirqs_off_caller+0x86/0x130
        ? mark_lock+0xa6/0x920
        lock_acquire+0xcc/0x260
        ? lock_acquire+0xcc/0x260
        ? flush_work+0x215/0x350
        flush_work+0x236/0x350
        ? flush_work+0x215/0x350
        ? destroy_worker+0x170/0x170
        __cancel_work_timer+0x17d/0x210
        ? ___preempt_schedule+0x16/0x18
        cancel_work_sync+0x10/0x20
        cifsFileInfo_put+0x338/0x7f0
        cifs_writedata_release+0x2a/0x40
        ? cifs_writedata_release+0x2a/0x40
        cifs_writev_complete+0x29d/0x850
        ? preempt_count_sub+0x18/0xd0
        process_one_work+0x304/0x8e0
        worker_thread+0x9b/0x6a0
        kthread+0x1b2/0x200
        ? process_one_work+0x8e0/0x8e0
        ? kthread_create_on_node+0x40/0x40
        ret_from_fork+0x31/0x40
      
      This is a real warning.  Since the oplock is queued on the same
      workqueue this can deadlock if there is only one worker thread active
      for the workqueue (which will be the case during memory pressure when
      the rescuer thread is handling it).
      
      Furthermore, there is at least one other kind of hang possible due to
      the oplock break handling if there is only worker.  (This can be
      reproduced without introducing memory pressure by having passing 1 for
      the max_active parameter of cifsiod.) cifs_oplock_break() can wait
      indefintely in the filemap_fdatawait() while the cifs_writev_complete()
      work is blocked:
      
       sysrq: SysRq : Show Blocked State
         task                        PC stack   pid father
       kworker/0:1     D    0    16      2 0x00000000
       Workqueue: cifsiod cifs_oplock_break
       Call Trace:
        __schedule+0x562/0xf40
        ? mark_held_locks+0x4a/0xb0
        schedule+0x57/0xe0
        io_schedule+0x21/0x50
        wait_on_page_bit+0x143/0x190
        ? add_to_page_cache_lru+0x150/0x150
        __filemap_fdatawait_range+0x134/0x190
        ? do_writepages+0x51/0x70
        filemap_fdatawait_range+0x14/0x30
        filemap_fdatawait+0x3b/0x40
        cifs_oplock_break+0x651/0x710
        ? preempt_count_sub+0x18/0xd0
        process_one_work+0x304/0x8e0
        worker_thread+0x9b/0x6a0
        kthread+0x1b2/0x200
        ? process_one_work+0x8e0/0x8e0
        ? kthread_create_on_node+0x40/0x40
        ret_from_fork+0x31/0x40
       dd              D    0   683    171 0x00000000
       Call Trace:
        __schedule+0x562/0xf40
        ? mark_held_locks+0x29/0xb0
        schedule+0x57/0xe0
        io_schedule+0x21/0x50
        wait_on_page_bit+0x143/0x190
        ? add_to_page_cache_lru+0x150/0x150
        __filemap_fdatawait_range+0x134/0x190
        ? do_writepages+0x51/0x70
        filemap_fdatawait_range+0x14/0x30
        filemap_fdatawait+0x3b/0x40
        filemap_write_and_wait+0x4e/0x70
        cifs_flush+0x6a/0xb0
        filp_close+0x52/0xa0
        __close_fd+0xdc/0x150
        SyS_close+0x33/0x60
        entry_SYSCALL_64_fastpath+0x1f/0xbe
      
       Showing all locks held in the system:
       2 locks held by kworker/0:1/16:
        #0:  ("cifsiod"){.+.+.+}, at: process_one_work+0x255/0x8e0
        #1:  ((&cfile->oplock_break)){+.+.+.}, at: process_one_work+0x255/0x8e0
      
       Showing busy workqueues and worker pools:
       workqueue cifsiod: flags=0xc
         pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/1
           in-flight: 16:cifs_oplock_break
           delayed: cifs_writev_complete, cifs_echo_request
       pool 0: cpus=0 node=0 flags=0x0 nice=0 hung=0s workers=3 idle: 750 3
      
      Fix these problems by creating a a new workqueue (with a rescuer) for
      the oplock break work.
      Signed-off-by: default avatarRabin Vincent <rabinv@axis.com>
      Signed-off-by: default avatarSteve French <smfrench@gmail.com>
      [bwh: Backported to 3.16: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      2080cbfa
    • YueHaibing's avatar
      tg3: don't clear stats while tg3_close · a8da8ec4
      YueHaibing authored
      commit 37a7fdf2 upstream.
      
      Now tg3 NIC's stats will be cleared after ifdown/ifup. bond_get_stats traverse
      its salves to get statistics,cumulative the increment.If a tg3 NIC is added to
      bonding as a slave,ifdown/ifup will cause bonding's stats become tremendous value
      (ex.1638.3 PiB) because of negative increment.
      
      Fixes: 92feeabf ("tg3: Save stats across chip resets")
      Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      a8da8ec4
    • James Hogan's avatar
      metag/uaccess: Check access_ok in strncpy_from_user · 641ddffc
      James Hogan authored
      commit 3a158a62 upstream.
      
      The metag implementation of strncpy_from_user() doesn't validate the src
      pointer, which could allow reading of arbitrary kernel memory. Add a
      short access_ok() check to prevent that.
      
      Its still possible for it to read across the user/kernel boundary, but
      it will invariably reach a NUL character after only 9 bytes, leaking
      only a static kernel address being loaded into D0Re0 at the beginning of
      __start, which is acceptable for the immediate fix.
      Reported-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Cc: linux-metag@vger.kernel.org
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      641ddffc
    • Steve French's avatar
      Set unicode flag on cifs echo request to avoid Mac error · 9690ad86
      Steve French authored
      commit 26c9cb66 upstream.
      
      Mac requires the unicode flag to be set for cifs, even for the smb
      echo request (which doesn't have strings).
      
      Without this Mac rejects the periodic echo requests (when mounting
      with cifs) that we use to check if server is down
      Signed-off-by: default avatarSteve French <smfrench@gmail.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      9690ad86
    • Dan Carpenter's avatar
      cifs: small underflow in cnvrtDosUnixTm() · 888d12a2
      Dan Carpenter authored
      commit 564277ec upstream.
      
      January is month 1.  There is no zero-th month.  If someone passes a
      zero month then it means we read from one space before the start of the
      total_days_of_prev_months[] array.
      
      We may as well also be strict about days as well.
      
      Fixes: 1bd5bbcb ("[CIFS] Legacy time handling for Win9x and OS/2 part 1")
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarSteve French <smfrench@gmail.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      888d12a2
    • Eric Dumazet's avatar
      tcp: fix wraparound issue in tcp_lp · ce5dde39
      Eric Dumazet authored
      commit a9f11f96 upstream.
      
      Be careful when comparing tcp_time_stamp to some u32 quantity,
      otherwise result can be surprising.
      
      Fixes: 7c106d7e ("[TCP]: TCP Low Priority congestion control")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [bwh: Backported to 3.16: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      ce5dde39
    • James Hogan's avatar
      metag/uaccess: Fix access_ok() · c58462a5
      James Hogan authored
      commit 8a8b5663 upstream.
      
      The __user_bad() macro used by access_ok() has a few corner cases
      noticed by Al Viro where it doesn't behave correctly:
      
       - The kernel range check has off by 1 errors which permit access to the
         first and last byte of the kernel mapped range.
      
       - The kernel range check ends at LINCORE_BASE rather than
         META_MEMORY_LIMIT, which is ineffective when the kernel is in global
         space (an extremely uncommon configuration).
      
      There are a couple of other shortcomings here too:
      
       - Access to the whole of the other address space is permitted (i.e. the
         global half of the address space when the kernel is in local space).
         This isn't ideal as it could theoretically still contain privileged
         mappings set up by the bootloader.
      
       - The size argument is unused, permitting user copies which start on
         valid pages at the end of the user address range and cross the
         boundary into the kernel address space (e.g. addr = 0x3ffffff0, size
         > 0x10).
      
      It isn't very convenient to add size checks when disallowing certain
      regions, and it seems far safer to be sure and explicit about what
      userland is able to access, so invert the logic to allow certain regions
      instead, and fix the off by 1 errors and missing size checks. This also
      allows the get_fs() == KERNEL_DS check to be more easily optimised into
      the user address range case.
      
      We now have 3 such allowed regions:
      
       - The user address range (incorporating the get_fs() == KERNEL_DS
         check).
      
       - NULL (some kernel code expects this to work, and we'll always catch
         the fault anyway).
      
       - The core code memory region.
      
      Fixes: 373cd784 ("metag: Memory handling")
      Reported-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Cc: linux-metag@vger.kernel.org
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      c58462a5
    • Russell Currey's avatar
      powerpc/eeh: Avoid use after free in eeh_handle_special_event() · f40caa4d
      Russell Currey authored
      commit daeba295 upstream.
      
      eeh_handle_special_event() is called when an EEH event is detected but
      can't be narrowed down to a specific PE.  This function looks through
      every PE to find one in an erroneous state, then calls the regular event
      handler eeh_handle_normal_event() once it knows which PE has an error.
      
      However, if eeh_handle_normal_event() found that the PE cannot possibly
      be recovered, it will free it, rendering the passed PE stale.
      This leads to a use after free in eeh_handle_special_event() as it attempts to
      clear the "recovering" state on the PE after eeh_handle_normal_event() returns.
      
      Thus, make sure the PE is valid when attempting to clear state in
      eeh_handle_special_event().
      
      Fixes: 8a6b1bc7 ("powerpc/eeh: EEH core to handle special event")
      Reported-by: default avatarAlexey Kardashevskiy <aik@ozlabs.ru>
      Signed-off-by: default avatarRussell Currey <ruscur@russell.cc>
      Reviewed-by: default avatarGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      [bwh: Backported to 3.16: adjust context, indentation]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      f40caa4d
    • Mario Kleiner's avatar
      drm/edid: Add 10 bpc quirk for LGD 764 panel in HP zBook 17 G2 · 7d7bf9b4
      Mario Kleiner authored
      commit e345da82 upstream.
      
      The builtin eDP panel in the HP zBook 17 G2 supports 10 bpc,
      as advertised by the Laptops product specs and verified via
      injecting a fixed edid + photometer measurements, but edid
      reports unknown depth, so drivers fall back to 6 bpc.
      
      Add a quirk to get the full 10 bpc.
      Signed-off-by: default avatarMario Kleiner <mario.kleiner.de@gmail.com>
      Acked-by: default avatarHarry Wentland <harry.wentland@amd.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/1492787108-23959-1-git-send-email-mario.kleiner.de@gmail.comSigned-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      7d7bf9b4
    • Marc Zyngier's avatar
      arm64: KVM: Fix decoding of Rt/Rt2 when trapping AArch32 CP accesses · 0ed60bc1
      Marc Zyngier authored
      commit c667186f upstream.
      
      Our 32bit CP14/15 handling inherited some of the ARMv7 code for handling
      the trapped system registers, completely missing the fact that the
      fields for Rt and Rt2 are now 5 bit wide, and not 4...
      
      Let's fix it, and provide an accessor for the most common Rt case.
      Reviewed-by: default avatarChristoffer Dall <cdall@linaro.org>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarChristoffer Dall <cdall@linaro.org>
      [bwh: Backported to 3.16:
       - Use literal numbers in kvm_vcpu_sys_get_rt()
       - Adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      0ed60bc1
    • Mikulas Patocka's avatar
      dm bufio: avoid a possible ABBA deadlock · 4171fcef
      Mikulas Patocka authored
      commit 1b0fb5a5 upstream.
      
      __get_memory_limit() tests if dm_bufio_cache_size changed and calls
      __cache_size_refresh() if it did.  It takes dm_bufio_clients_lock while
      it already holds the client lock.  However, lock ordering is violated
      because in cleanup_old_buffers() dm_bufio_clients_lock is taken before
      the client lock.
      
      This results in a possible deadlock and lockdep engine warning.
      
      Fix this deadlock by changing mutex_lock() to mutex_trylock().  If the
      lock can't be taken, it will be re-checked next time when a new buffer
      is allocated.
      
      Also add "unlikely" to the if condition, so that the optimizer assumes
      that the condition is false.
      Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      4171fcef
    • David S. Miller's avatar
      ipv6: Need to export ipv6_push_frag_opts for tunneling now. · 44fda124
      David S. Miller authored
      commit 5b8481fa upstream.
      
      Since that change also made the nfrag function not necessary
      for exports, remove it.
      
      Fixes: 89a23c8b ("ip6_tunnel: Fix missing tunnel encapsulation limit option")
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [bwh: Backported to 3.16: keep exporting ipv6_push_nfrag_opts(), needed by
       ip6_gre module]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      44fda124
    • Craig Gallek's avatar
      ip6_tunnel: Fix missing tunnel encapsulation limit option · c36e890c
      Craig Gallek authored
      commit 89a23c8b upstream.
      
      The IPv6 tunneling code tries to insert IPV6_TLV_TNL_ENCAP_LIMIT and
      IPV6_TLV_PADN options when an encapsulation limit is defined (the
      default is a limit of 4).  An MTU adjustment is done to account for
      these options as well.  However, the options are never present in the
      generated packets.
      
      The issue appears to be a subtlety between IPV6_DSTOPTS and
      IPV6_RTHDRDSTOPTS defined in RFC 3542.  When the IPIP tunnel driver was
      written, the encap limit options were included as IPV6_RTHDRDSTOPTS in
      dst0opt of struct ipv6_txoptions.  Later, ipv6_push_nfrags_opts was
      (correctly) updated to require IPV6_RTHDR options when IPV6_RTHDRDSTOPTS
      are to be used.  This caused the options to no longer be included in v6
      encapsulated packets.
      
      The fix is to use IPV6_DSTOPTS (in dst1opt of struct ipv6_txoptions)
      instead.  IPV6_DSTOPTS do not have the additional IPV6_RTHDR requirement.
      
      Fixes: 1df64a85: ("[IPV6]: Add ip6ip6 tunnel driver.")
      Fixes: 333fad53: ("[IPV6]: Support several new sockopt / ancillary data in Advanced API (RFC3542)")
      Signed-off-by: default avatarCraig Gallek <kraig@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [bwh: Backported to 3.16: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      c36e890c
    • Sebastian Reichel's avatar
      Input: twl4030-pwrbutton - use correct device for irq request · e1a68716
      Sebastian Reichel authored
      commit 3071e9dd upstream.
      
      The interrupt should be requested for the platform device
      and not for the input device.
      
      Fixes: 7f9ce649 ("Input: twl4030-pwrbutton - simplify driver using devm_*")
      Signed-off-by: default avatarSebastian Reichel <sebastian.reichel@collabora.co.uk>
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      [bwh: Backported to 3.16: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      e1a68716
    • Michael Trimarchi's avatar
      power: supply: pda_power: move from timer to delayed_work · 8a450fa9
      Michael Trimarchi authored
      commit 633e8799 upstream.
      
      This changed is needed to avoid locking problem during
      boot as shown:
      
      <5>[    8.824096] Registering SWP/SWPB emulation handler
      <6>[    8.977294] clock: disabling unused clocks to save power
      <3>[    9.108154] BUG: sleeping function called from invalid context at kernel_albert/kernel/mutex.c:269
      <3>[    9.122894] in_atomic(): 1, irqs_disabled(): 0, pid: 1, name: swapper/0
      <4>[    9.130249] 3 locks held by swapper/0/1:
      <4>[    9.134613]  #0:  (&__lockdep_no_validate__){......}, at: [<c0342430>] __driver_attach+0x58/0xa8
      <4>[    9.144500]  #1:  (&__lockdep_no_validate__){......}, at: [<c0342440>] __driver_attach+0x68/0xa8
      <4>[    9.154357]  #2:  (&polling_timer){......}, at: [<c0053770>] run_timer_softirq+0x108/0x3ec
      <4>[    9.163726] Backtrace:
      <4>[    9.166473] [<c001269c>] (dump_backtrace+0x0/0x114) from [<c067e5f0>] (dump_stack+0x20/0x24)
      <4>[    9.175811]  r6:00203230 r5:0000010d r4:d782e000 r3:60000113
      <4>[    9.182250] [<c067e5d0>] (dump_stack+0x0/0x24) from [<c007441c>] (__might_sleep+0x10c/0x128)
      <4>[    9.191650] [<c0074310>] (__might_sleep+0x0/0x128) from [<c0688f60>] (mutex_lock_nested+0x34/0x36c)
      <4>[    9.201660]  r5:c02d5350 r4:d79a0c64
      <4>[    9.205688] [<c0688f2c>] (mutex_lock_nested+0x0/0x36c) from [<c02d5350>] (regulator_set_current_limit+0x30/0x118)
      <4>[    9.217071] [<c02d5320>] (regulator_set_current_limit+0x0/0x118) from [<c0435ce0>] (update_charger+0x84/0xc4)
      <4>[    9.228027]  r7:d782fb20 r6:00000101 r5:c1767e94 r4:00000000
      <4>[    9.234436] [<c0435c5c>] (update_charger+0x0/0xc4) from [<c0435d40>] (psy_changed+0x20/0x48)
      <4>[    9.243804]  r5:d782e000 r4:c1767e94
      <4>[    9.247802] [<c0435d20>] (psy_changed+0x0/0x48) from [<c0435dec>] (polling_timer_func+0x84/0xb8)
      <4>[    9.257537]  r4:c1767e94 r3:00000002
      <4>[    9.261566] [<c0435d68>] (polling_timer_func+0x0/0xb8) from [<c00537e4>] (run_timer_softirq+0x17c/0x3ec)
      <4>[    9.272033]  r4:c1767eb0 r3:00000000
      <4>[    9.276062] [<c0053668>] (run_timer_softirq+0x0/0x3ec) from [<c004b000>] (__do_softirq+0xf0/0x298)
      <4>[    9.286010] [<c004af10>] (__do_softirq+0x0/0x298) from [<c004b650>] (irq_exit+0x98/0xa0)
      <4>[    9.295013] [<c004b5b8>] (irq_exit+0x0/0xa0) from [<c000edbc>] (handle_IRQ+0x60/0xc0)
      <4>[    9.303680]  r4:c1194e98 r3:c00bc778
      <4>[    9.307708] [<c000ed5c>] (handle_IRQ+0x0/0xc0) from [<c0008504>] (gic_handle_irq+0x34/0x68)
      <4>[    9.316955]  r8:000ac383 r7:d782fc3c r6:d782fc08 r5:c11936c4 r4:e0802100
      <4>[    9.324310] r3:c026ba48
      <4>[    9.327301] [<c00084d0>] (gic_handle_irq+0x0/0x68) from [<c068c2c0>] (__irq_svc+0x40/0x74)
      <4>[    9.336456] Exception stack(0xd782fc08 to 0xd782fc50)
      <4>[    9.342041] fc00:                   d6e30e6c ac383627 00000000 ac383417 ea19c000 ea200000
      <4>[    9.351104] fc20: beffffff 00000667 000ac383 d6e30670 d6e3066c d782fc94 d782fbe8 d782fc50
      <4>[    9.360168] fc40: c026ba48 c001d1f0 00000113 ffffffff
      
      Fixes: b2998049 ("[BATTERY] pda_power platform driver")
      Signed-off-by: default avatarMichael Trimarchi <michael@amarulasolutions.com>
      Signed-off-by: default avatarAnthony Brandon <anthony@amarulasolutions.com>
      Signed-off-by: default avatarSebastian Reichel <sebastian.reichel@collabora.co.uk>
      [bwh: Backported to 3.16: adjust filename]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      8a450fa9
    • Pan Bian's avatar
      power: supply: isp1704: Fix unchecked return value of devm_kzalloc · df5a28b8
      Pan Bian authored
      commit 8b208399 upstream.
      
      Function devm_kzalloc() will return a NULL pointer. However, in function
      isp1704_charger_probe(), the return value of devm_kzalloc() is directly
      used without validation. This may result in a bad memory access bug.
      
      Fixes: 34a10961 ("isp1704_charger: Add DT support")
      Signed-off-by: default avatarPan Bian <bianpan2016@163.com>
      Reviewed-by: default avatarPali Rohár <pali.rohar@gmail.com>
      Signed-off-by: default avatarSebastian Reichel <sebastian.reichel@collabora.co.uk>
      [bwh: Backported to 3.16: adjust filename]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      df5a28b8
    • Szymon Janc's avatar
      Bluetooth: Fix user channel for 32bit userspace on 64bit kernel · 84a0a2ec
      Szymon Janc authored
      commit ab89f0bd upstream.
      
      Running 32bit userspace on 64bit kernel results in MSG_CMSG_COMPAT being
      defined as 0x80000000. This results in sendmsg failure if used from 32bit
      userspace running on 64bit kernel. Fix this by accounting for MSG_CMSG_COMPAT
      in flags check in hci_sock_sendmsg.
      Signed-off-by: default avatarSzymon Janc <szymon.janc@codecoup.pl>
      Signed-off-by: default avatarMarko Kiiskila <marko@runtime.io>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      84a0a2ec
    • Christophe Leroy's avatar
      net: ethernet: ucc_geth: fix MEM_PART_MURAM mode · c4e387c8
      Christophe Leroy authored
      commit 8b8642af upstream.
      
      Since commit 5093bb96 ("powerpc/QE: switch to the cpm_muram
      implementation"), muram area is not part of immrbar mapping anymore
      so immrbar_virt_to_phys() is not usable anymore.
      
      Fixes: 5093bb96 ("powerpc/QE: switch to the cpm_muram implementation")
      Signed-off-by: default avatarChristophe Leroy <christophe.leroy@c-s.fr>
      Acked-by: default avatarDavid S. Miller <davem@davemloft.net>
      Acked-by: default avatarLi Yang <pku.leo@gmail.com>
      Signed-off-by: default avatarScott Wood <oss@buserror.net>
      [bwh: Backported to 3.16: adjust filename]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      c4e387c8
    • Eric Biggers's avatar
      ext4: evict inline data when writing to memory map · 59b4a049
      Eric Biggers authored
      commit 7b4cc978 upstream.
      
      Currently the case of writing via mmap to a file with inline data is not
      handled.  This is maybe a rare case since it requires a writable memory
      map of a very small file, but it is trivial to trigger with on
      inline_data filesystem, and it causes the
      'BUG_ON(ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA));' in
      ext4_writepages() to be hit:
      
          mkfs.ext4 -O inline_data /dev/vdb
          mount /dev/vdb /mnt
          xfs_io -f /mnt/file \
      	-c 'pwrite 0 1' \
      	-c 'mmap -w 0 1m' \
      	-c 'mwrite 0 1' \
      	-c 'fsync'
      
      	kernel BUG at fs/ext4/inode.c:2723!
      	invalid opcode: 0000 [#1] SMP
      	CPU: 1 PID: 2532 Comm: xfs_io Not tainted 4.11.0-rc1-xfstests-00301-g071d9acf3d1f #633
      	Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-20170228_101828-anatol 04/01/2014
      	task: ffff88003d3a8040 task.stack: ffffc90000300000
      	RIP: 0010:ext4_writepages+0xc89/0xf8a
      	RSP: 0018:ffffc90000303ca0 EFLAGS: 00010283
      	RAX: 0000028410000000 RBX: ffff8800383fa3b0 RCX: ffffffff812afcdc
      	RDX: 00000a9d00000246 RSI: ffffffff81e660e0 RDI: 0000000000000246
      	RBP: ffffc90000303dc0 R08: 0000000000000002 R09: 869618e8f99b4fa5
      	R10: 00000000852287a2 R11: 00000000a03b49f4 R12: ffff88003808e698
      	R13: 0000000000000000 R14: 7fffffffffffffff R15: 7fffffffffffffff
      	FS:  00007fd3e53094c0(0000) GS:ffff88003e400000(0000) knlGS:0000000000000000
      	CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      	CR2: 00007fd3e4c51000 CR3: 000000003d554000 CR4: 00000000003406e0
      	Call Trace:
      	 ? _raw_spin_unlock+0x27/0x2a
      	 ? kvm_clock_read+0x1e/0x20
      	 do_writepages+0x23/0x2c
      	 ? do_writepages+0x23/0x2c
      	 __filemap_fdatawrite_range+0x80/0x87
      	 filemap_write_and_wait_range+0x67/0x8c
      	 ext4_sync_file+0x20e/0x472
      	 vfs_fsync_range+0x8e/0x9f
      	 ? syscall_trace_enter+0x25b/0x2d0
      	 vfs_fsync+0x1c/0x1e
      	 do_fsync+0x31/0x4a
      	 SyS_fsync+0x10/0x14
      	 do_syscall_64+0x69/0x131
      	 entry_SYSCALL64_slow_path+0x25/0x25
      
      We could try to be smart and keep the inline data in this case, or at
      least support delayed allocation when allocating the block, but these
      solutions would be more complicated and don't seem worthwhile given how
      rare this case seems to be.  So just fix the bug by calling
      ext4_convert_inline_data() when we're asked to make a page writable, so
      that any inline data gets evicted, with the block allocated immediately.
      Reported-by: default avatarNick Alcock <nick.alcock@oracle.com>
      Reviewed-by: default avatarAndreas Dilger <adilger@dilger.ca>
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      [bwh: Backported to 3.16: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      59b4a049
    • Christoph Hellwig's avatar
      libata: reject passthrough WRITE SAME requests · 0256d09d
      Christoph Hellwig authored
      commit c6ade20f upstream.
      
      The WRITE SAME to TRIM translation rewrites the DATA OUT buffer.  While
      the SCSI code accomodates for this by passing a read-writable buffer
      userspace applications don't cater for this behavior.  In fact it can
      be used to rewrite e.g. a readonly file through mmap and should be
      considered as a security fix.
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Reviewed-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      [bwh: Backported to 3.16:
       - Open-code blk_rq_is_passthrough()
       - We don't distinguish which field is invaid so goto invalid_fld
       - Adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      0256d09d
    • Michael J. Ruhl's avatar
      IB/core: For multicast functions, verify that LIDs are multicast LIDs · ffbd148d
      Michael J. Ruhl authored
      commit 8561eae6 upstream.
      
      The Infiniband spec defines "A multicast address is defined by a
      MGID and a MLID" (section 10.5).  Currently the MLID value is not
      validated.
      
      Add check to verify that the MLID value is in the correct address
      range.
      
      Fixes: 0c33aeed ("[IB] Add checks to multicast attach and detach")
      Reviewed-by: default avatarIra Weiny <ira.weiny@intel.com>
      Reviewed-by: default avatarDasaratharaman Chandramouli <dasaratharaman.chandramouli@intel.com>
      Signed-off-by: default avatarMichael J. Ruhl <michael.j.ruhl@intel.com>
      Signed-off-by: default avatarDennis Dalessandro <dennis.dalessandro@intel.com>
      Reviewed-by: default avatarLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      [bwh: Backported to 3.16: use literal number instead of IB_MULTICAST_LID_BASE]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      ffbd148d
    • Michael J. Ruhl's avatar
      IB/core: If the MGID/MLID pair is not on the list return an error · 5a5271b4
      Michael J. Ruhl authored
      commit 20c7840a upstream.
      
      A list of MGID/MLID pairs is built when doing a multicast attach.  When
      the multicast detach is called, the list is searched, and regardless of
      the search outcome, the driver detach is called.
      
      If an MGID/MLID pair is not on the list, driver detach should not be
      called, and an error should be returned.  Calling the driver without
      removing an MGID/MLID pair from the list can leave the core and driver
      out of sync.
      
      Fixes: f4e40156 ("IB/uverbs: track multicast group membership for userspace QPs")
      Reviewed-by: default avatarIra Weiny <ira.weiny@intel.com>
      Reviewed-by: default avatarLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: default avatarMichael J. Ruhl <michael.j.ruhl@intel.com>
      Signed-off-by: default avatarDennis Dalessandro <dennis.dalessandro@intel.com>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      [bwh: Backported to 3.16: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      5a5271b4
    • Johan Hovold's avatar
      staging: gdm724x: gdm_mux: fix use-after-free on module unload · e106f1b5
      Johan Hovold authored
      commit b58f45c8 upstream.
      
      Make sure to deregister the USB driver before releasing the tty driver
      to avoid use-after-free in the USB disconnect callback where the tty
      devices are deregistered.
      
      Fixes: 61e12104 ("staging: gdm7240: adding LTE USB driver")
      Cc: Won Kang <wkang77@gmail.com>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      e106f1b5
    • Amitoj Kaur Chawla's avatar
      staging: gdm724x: gdm_mux: Remove create_workqueue() · 88468b0d
      Amitoj Kaur Chawla authored
      commit c272dc2d upstream.
      
      With concurrency managed workqueues, use of dedicated workqueues
      can be replaced by using system_wq. Drop mux_rx_wq by using system_wq.
      
      Since there is only one work item per mux_dev and different mux_devs
      do not need to be ordered, increase of concurrency level by switching
      to system_wq should not break anything.
      
      cancel_work_sync() is used to ensure that work is not pending or
      executing on any CPU.
      
      Lastly, since all devices are suspended, which shutdowns the work item
      before the driver can be unregistered, it is guaranteed that no work
      item is pending or executing by the time exit path runs.
      Signed-off-by: default avatarAmitoj Kaur Chawla <amitoj1606@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      [bwh: Backported to 3.16: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      88468b0d
    • Dan Carpenter's avatar
      staging: rtl8188eu: prevent an underflow in rtw_check_beacon_data() · a61e93c5
      Dan Carpenter authored
      commit 784047eb upstream.
      
      The "len" could be as low as -14 so we should check for negatives.
      
      Fixes: 9a7fe54d ("staging: r8188eu: Add source files for new driver - part 1")
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      a61e93c5
    • Adrian Salido's avatar
      dm ioctl: prevent stack leak in dm ioctl call · aebe2f15
      Adrian Salido authored
      commit 4617f564 upstream.
      
      When calling a dm ioctl that doesn't process any data
      (IOCTL_FLAGS_NO_PARAMS), the contents of the data field in struct
      dm_ioctl are left initialized.  Current code is incorrectly extending
      the size of data copied back to user, causing the contents of kernel
      stack to be leaked to user.  Fix by only copying contents before data
      and allow the functions processing the ioctl to override.
      Signed-off-by: default avatarAdrian Salido <salidoa@google.com>
      Reviewed-by: default avatarAlasdair G Kergon <agk@redhat.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      aebe2f15