1. 15 Sep, 2017 13 commits
  2. 26 Aug, 2017 27 commits
    • Ben Hutchings's avatar
      Linux 3.16.47 · f4a99fcb
      Ben Hutchings authored
      f4a99fcb
    • Talat Batheesh's avatar
      net/mlx4: Fix the check in attaching steering rules · d3d010b3
      Talat Batheesh authored
      commit 6dc06c08 upstream.
      
      Our previous patch (cited below) introduced a regression
      for RAW Eth QPs.
      
      Fix it by checking if the QP number provided by user-space
      exists, hence allowing steering rules to be added for valid
      QPs only.
      
      Fixes: 89c55768 ("net/mlx4_en: Avoid adding steering rules with invalid ring")
      Reported-by: default avatarOr Gerlitz <gerlitz.or@gmail.com>
      Signed-off-by: default avatarTalat Batheesh <talatb@mellanox.com>
      Signed-off-by: default avatarTariq Toukan <tariqt@mellanox.com>
      Acked-by: default avatarOr Gerlitz <ogerlitz@mellanox.com>
      Reviewed-by: default avatarLeon Romanovsky <leonro@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>
      d3d010b3
    • Maksim Salau's avatar
      usb: misc: legousbtower: Fix memory leak · 14216e1b
      Maksim Salau authored
      commit 0bd193d6 upstream.
      
      get_version_reply is not freed if function returns with success.
      
      Fixes: 942a4873 ("usb: misc: legousbtower: Fix buffers on stack")
      Reported-by: default avatarHeikki Krogerus <heikki.krogerus@linux.intel.com>
      Signed-off-by: default avatarMaksim Salau <maksim.salau@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      14216e1b
    • Willem de Bruijn's avatar
      udp: consistently apply ufo or fragmentation · 08676246
      Willem de Bruijn authored
      commit 85f1bd9a upstream.
      
      When iteratively building a UDP datagram with MSG_MORE and that
      datagram exceeds MTU, consistently choose UFO or fragmentation.
      
      Once skb_is_gso, always apply ufo. Conversely, once a datagram is
      split across multiple skbs, do not consider ufo.
      
      Sendpage already maintains the first invariant, only add the second.
      IPv6 does not have a sendpage implementation to modify.
      
      A gso skb must have a partial checksum, do not follow sk_no_check_tx
      in udp_send_skb.
      
      Found by syzkaller.
      
      Fixes: e89e9cf5 ("[IPv4/IPv6]: UFO Scatter-gather approach")
      Reported-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Signed-off-by: default avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      [bwh: Backported to 3.16:
       - ip6_append_data() doesn't take a queue parameter; use &sk->sk_write_queue
       - Adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      08676246
    • Zheng Li's avatar
      ipv6: Should use consistent conditional judgement for ip6 fragment between... · df3d6afc
      Zheng Li authored
      ipv6: Should use consistent conditional judgement for ip6 fragment between __ip6_append_data and ip6_finish_output
      
      commit e4c5e13a upstream.
      
      There is an inconsistent conditional judgement between __ip6_append_data
      and ip6_finish_output functions, the variable length in __ip6_append_data
      just include the length of application's payload and udp6 header, don't
      include the length of ipv6 header, but in ip6_finish_output use
      (skb->len > ip6_skb_dst_mtu(skb)) as judgement, and skb->len include the
      length of ipv6 header.
      
      That causes some particular application's udp6 payloads whose length are
      between (MTU - IPv6 Header) and MTU were fragmented by ip6_fragment even
      though the rst->dev support UFO feature.
      
      Add the length of ipv6 header to length in __ip6_append_data to keep
      consistent conditional judgement as ip6_finish_output for ip6 fragment.
      Signed-off-by: default avatarZheng Li <james.z.li@ericsson.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      df3d6afc
    • Willem de Bruijn's avatar
      packet: fix tp_reserve race in packet_set_ring · ec26c86f
      Willem de Bruijn authored
      commit c27927e3 upstream.
      
      Updates to tp_reserve can race with reads of the field in
      packet_set_ring. Avoid this by holding the socket lock during
      updates in setsockopt PACKET_RESERVE.
      
      This bug was discovered by syzkaller.
      
      Fixes: 8913336a ("packet: add PACKET_RESERVE sockopt")
      Reported-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Signed-off-by: default avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      ec26c86f
    • Cong Wang's avatar
      mqueue: fix a use-after-free in sys_mq_notify() · b6ec0534
      Cong Wang authored
      commit f991af3d upstream.
      
      The retry logic for netlink_attachskb() inside sys_mq_notify()
      is nasty and vulnerable:
      
      1) The sock refcnt is already released when retry is needed
      2) The fd is controllable by user-space because we already
         release the file refcnt
      
      so we when retry but the fd has been just closed by user-space
      during this small window, we end up calling netlink_detachskb()
      on the error path which releases the sock again, later when
      the user-space closes this socket a use-after-free could be
      triggered.
      
      Setting 'sock' to NULL here should be sufficient to fix it.
      Reported-by: default avatarGeneBlue <geneblue.mail@gmail.com>
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Manfred Spraul <manfred@colorfullife.com>
      Cc: stable@kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      b6ec0534
    • Thomas Gleixner's avatar
      timerfd: Protect the might cancel mechanism proper · e7467c79
      Thomas Gleixner authored
      commit 1e38da30 upstream.
      
      The handling of the might_cancel queueing is not properly protected, so
      parallel operations on the file descriptor can race with each other and
      lead to list corruptions or use after free.
      
      Protect the context for these operations with a seperate lock.
      
      The wait queue lock cannot be reused for this because that would create a
      lock inversion scenario vs. the cancel lock. Replacing might_cancel with an
      atomic (atomic_t or atomic bit) does not help either because it still can
      race vs. the actual list operation.
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: "linux-fsdevel@vger.kernel.org"
      Cc: syzkaller <syzkaller@googlegroups.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: linux-fsdevel@vger.kernel.org
      Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1701311521430.3457@nanosSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      e7467c79
    • Sabrina Dubroca's avatar
      ipv6: avoid overflow of offset in ip6_find_1stfragopt · 276cb60b
      Sabrina Dubroca authored
      commit 6399f1fa upstream.
      
      In some cases, offset can overflow and can cause an infinite loop in
      ip6_find_1stfragopt(). Make it unsigned int to prevent the overflow, and
      cap it at IPV6_MAXPLEN, since packets larger than that should be invalid.
      
      This problem has been here since before the beginning of git history.
      Signed-off-by: default avatarSabrina Dubroca <sd@queasysnail.net>
      Acked-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      276cb60b
    • Al Viro's avatar
      dentry name snapshots · 2cbc76ab
      Al Viro authored
      commit 49d31c2f upstream.
      
      take_dentry_name_snapshot() takes a safe snapshot of dentry name;
      if the name is a short one, it gets copied into caller-supplied
      structure, otherwise an extra reference to external name is grabbed
      (those are never modified).  In either case the pointer to stable
      string is stored into the same structure.
      
      dentry must be held by the caller of take_dentry_name_snapshot(),
      but may be freely dropped afterwards - the snapshot will stay
      until destroyed by release_dentry_name_snapshot().
      
      Intended use:
      	struct name_snapshot s;
      
      	take_dentry_name_snapshot(&s, dentry);
      	...
      	access s.name
      	...
      	release_dentry_name_snapshot(&s);
      
      Replaces fsnotify_oldname_...(), gets used in fsnotify to obtain the name
      to pass down with event.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      [carnil: backport 4.9: adjust context]
      [bwh: Backported to 3.16:
       - External names are not ref-counted, so copy them
       - Adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      2cbc76ab
    • Alexander Tsoy's avatar
      ath9k_htc: add device ID for Toshiba WLM-20U2/GN-1080 · 367a39d4
      Alexander Tsoy authored
      commit aea57edf upstream.
      
      This device is available under different marketing names:
      WLM-20U2 - Wireless USB Dongle for Toshiba TVs
      GN-1080 - Wireless LAN Module for Toshiba MFPs.
      Signed-off-by: default avatarAlexander Tsoy <alexander@tsoy.me>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      367a39d4
    • 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