1. 08 Jun, 2017 8 commits
  2. 28 May, 2017 7 commits
  3. 17 May, 2017 25 commits
    • Nicholas Bellinger's avatar
      iscsi-target: Set session_fall_back_to_erl0 when forcing reinstatement · 14f24a46
      Nicholas Bellinger authored
      [ Upstream commit 197b806a ]
      
      While testing modification of per se_node_acl queue_depth forcing
      session reinstatement via lio_target_nacl_cmdsn_depth_store() ->
      core_tpg_set_initiator_node_queue_depth(), a hung task bug triggered
      when changing cmdsn_depth invoked session reinstatement while an iscsi
      login was already waiting for session reinstatement to complete.
      
      This can happen when an outstanding se_cmd descriptor is taking a
      long time to complete, and session reinstatement from iscsi login
      or cmdsn_depth change occurs concurrently.
      
      To address this bug, explicitly set session_fall_back_to_erl0 = 1
      when forcing session reinstatement, so session reinstatement is
      not attempted if an active session is already being shutdown.
      
      This patch has been tested with two scenarios.  The first when
      iscsi login is blocked waiting for iscsi session reinstatement
      to complete followed by queue_depth change via configfs, and
      second when queue_depth change via configfs us blocked followed
      by a iscsi login driven session reinstatement.
      
      Note this patch depends on commit d36ad77f to handle multiple
      sessions per se_node_acl when changing cmdsn_depth, and for
      pre v4.5 kernels will need to be included for stable as well.
      Reported-by: default avatarGary Guo <ghg@datera.io>
      Tested-by: default avatarGary Guo <ghg@datera.io>
      Cc: Gary Guo <ghg@datera.io>
      Cc: <stable@vger.kernel.org> # v4.1+
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      14f24a46
    • Nicholas Bellinger's avatar
      target: Fix compare_and_write_callback handling for non GOOD status · 3aa99b61
      Nicholas Bellinger authored
      [ Upstream commit a71a5dc7 ]
      
      Following the bugfix for handling non SAM_STAT_GOOD COMPARE_AND_WRITE
      status during COMMIT phase in commit 9b2792c3, the same bug exists
      for the READ phase as well.
      
      This would manifest first as a lost SCSI response, and eventual
      hung task during fabric driver logout or re-login, as existing
      shutdown logic waited for the COMPARE_AND_WRITE se_cmd->cmd_kref
      to reach zero.
      
      To address this bug, compare_and_write_callback() has been changed
      to set post_ret = 1 and return TCM_LOGICAL_UNIT_COMMUNICATION_FAILURE
      as necessary to signal failure status.
      Reported-by: default avatarBill Borsari <wgb@datera.io>
      Cc: Bill Borsari <wgb@datera.io>
      Tested-by: default avatarGary Guo <ghg@datera.io>
      Cc: Gary Guo <ghg@datera.io>
      Cc: <stable@vger.kernel.org> # v4.1+
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      3aa99b61
    • Rob Herring's avatar
      of: fix sparse warning in of_pci_range_parser_one · 0c562305
      Rob Herring authored
      [ Upstream commit eb310036 ]
      
      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.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarRob Herring <robh@kernel.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      0c562305
    • Luis Henriques's avatar
      ceph: fix memory leak in __ceph_setxattr() · 3e9e9c70
      Luis Henriques authored
      [ Upstream commit eeca958d ]
      
      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
      
      Cc: stable@vger.kernel.org
      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 avatarSasha Levin <alexander.levin@verizon.com>
      3e9e9c70
    • Steve French's avatar
      SMB3: Work around mount failure when using SMB3 dialect to Macs · 009a8391
      Steve French authored
      [ Upstream commit 7db0a6ef ]
      
      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>
      CC: Stable <stable@vger.kernel.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      009a8391
    • Björn Jacke's avatar
      CIFS: fix mapping of SFM_SPACE and SFM_PERIOD · ffd28faa
      Björn Jacke authored
      [ Upstream commit b704e70b ]
      
      - trailing space maps to 0xF028
      - trailing period maps to 0xF029
      
      This fix corrects the mapping of file names which have a trailing character
      that would otherwise be illegal (period or space) but is allowed by POSIX.
      Signed-off-by: default avatarBjoern Jacke <bjacke@samba.org>
      CC: Stable <stable@vger.kernel.org>
      Signed-off-by: default avatarSteve French <smfrench@gmail.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      ffd28faa
    • Andrey Ryabinin's avatar
      fs/block_dev: always invalidate cleancache in invalidate_bdev() · ae5175c8
      Andrey Ryabinin authored
      [ Upstream commit a5f6a6a9 ]
      
      invalidate_bdev() calls cleancache_invalidate_inode() iff ->nrpages != 0
      which doen't make any sense.
      
      Make sure that invalidate_bdev() always calls cleancache_invalidate_inode()
      regardless of mapping->nrpages value.
      
      Fixes: c515e1fd ("mm/fs: add hooks to support cleancache")
      Link: http://lkml.kernel.org/r/20170424164135.22350-3-aryabinin@virtuozzo.comSigned-off-by: default avatarAndrey Ryabinin <aryabinin@virtuozzo.com>
      Reviewed-by: default avatarJan Kara <jack@suse.cz>
      Acked-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: Alexey Kuznetsov <kuznet@virtuozzo.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Nikolay Borisov <n.borisov.lkml@gmail.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      ae5175c8
    • Richard Weinberger's avatar
      um: Fix PTRACE_POKEUSER on x86_64 · e895a105
      Richard Weinberger authored
      [ Upstream commit 9abc74a2 ]
      
      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.
      
      Cc: <stable@vger.kernel.org>
      Reported-by: default avatarjie cao <cj3054@gmail.com>
      Signed-off-by: default avatarRichard Weinberger <richard@nod.at>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      e895a105
    • James Hogan's avatar
      metag/uaccess: Check access_ok in strncpy_from_user · 327d7855
      James Hogan authored
      [ Upstream commit 3a158a62 ]
      
      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
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      327d7855
    • Steve French's avatar
      Set unicode flag on cifs echo request to avoid Mac error · 31390049
      Steve French authored
      [ Upstream commit 26c9cb66 ]
      
      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>
      CC: Stable <stable@vger.kernel.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      31390049
    • James Hogan's avatar
      metag/uaccess: Fix access_ok() · 3ea80afb
      James Hogan authored
      [ Upstream commit 8a8b5663 ]
      
      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
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      3ea80afb
    • Bart Van Assche's avatar
      target: Fix VERIFY and WRITE VERIFY command parsing · 17535d26
      Bart Van Assche authored
      [ Upstream commit 0e2eb7d1 ]
      
      Use the value of the BYTCHK field to determine the size of the
      Data-Out buffer. For VERIFY, honor the VRPROTECT, DPO and FUA
      fields. This patch avoids that LIO complains about a mismatch
      between the expected transfer length and the SCSI CDB length
      if the value of the BYTCHK field is 0.
      Signed-off-by: default avatarBart Van Assche <bart.vanassche@sandisk.com>
      Cc: Max Lohrmann <post@wickenrode.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      17535d26
    • Mikulas Patocka's avatar
      dm bufio: check new buffer allocation watermark every 30 seconds · edd3ad16
      Mikulas Patocka authored
      [ Upstream commit 390020ad ]
      
      dm-bufio checks a watermark when it allocates a new buffer in
      __bufio_new().  However, it doesn't check the watermark when the user
      changes /sys/module/dm_bufio/parameters/max_cache_size_bytes.
      
      This may result in a problem - if the watermark is high enough so that
      all possible buffers are allocated and if the user lowers the value of
      "max_cache_size_bytes", the watermark will never be checked against the
      new value because no new buffer would be allocated.
      
      To fix this, change __evict_old_buffers() so that it checks the
      watermark.  __evict_old_buffers() is called every 30 seconds, so if the
      user reduces "max_cache_size_bytes", dm-bufio will react to this change
      within 30 seconds and decrease memory consumption.
      
      Depends-on: 1b0fb5a5 ("dm bufio: avoid a possible ABBA deadlock")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      edd3ad16
    • Mikulas Patocka's avatar
      dm bufio: avoid a possible ABBA deadlock · bbe86592
      Mikulas Patocka authored
      [ Upstream commit 1b0fb5a5 ]
      
      __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.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      bbe86592
    • Szymon Janc's avatar
      Bluetooth: Fix user channel for 32bit userspace on 64bit kernel · 9575253a
      Szymon Janc authored
      [ Upstream commit ab89f0bd ]
      
      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>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      9575253a
    • Eric Biggers's avatar
      ext4: evict inline data when writing to memory map · ca38d087
      Eric Biggers authored
      [ Upstream commit 7b4cc978 ]
      
      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>
      Cc: stable@vger.kernel.org
      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>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      ca38d087
    • Takashi Iwai's avatar
      proc: Fix unbalanced hard link numbers · 3a9700b0
      Takashi Iwai authored
      [ Upstream commit d66bb160 ]
      
      proc_create_mount_point() forgot to increase the parent's nlink, and
      it resulted in unbalanced hard link numbers, e.g. /proc/fs shows one
      less than expected.
      
      Fixes: eb6d38d5 ("proc: Allow creating permanently empty directories...")
      Cc: stable@vger.kernel.org
      Reported-by: default avatarTristan Ye <tristan.ye@suse.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      3a9700b0
    • Adrian Salido's avatar
      dm ioctl: prevent stack leak in dm ioctl call · 2279c8b9
      Adrian Salido authored
      [ Upstream commit 4617f564 ]
      
      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.
      
      Cc: stable@vger.kernel.org
      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 avatarSasha Levin <alexander.levin@verizon.com>
      2279c8b9
    • J. Bruce Fields's avatar
      nfsd: stricter decoding of write-like NFSv2/v3 ops · 5afff19d
      J. Bruce Fields authored
      [ Upstream commit 13bf9fbf ]
      
      The NFSv2/v3 code does not systematically check whether we decode past
      the end of the buffer.  This generally appears to be harmless, but there
      are a few places where we do arithmetic on the pointers involved and
      don't account for the possibility that a length could be negative.  Add
      checks to catch these.
      Reported-by: default avatarTuomas Haanpää <thaan@synopsys.com>
      Reported-by: default avatarAri Kauppi <ari@synopsys.com>
      Reviewed-by: default avatarNeilBrown <neilb@suse.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      5afff19d
    • J. Bruce Fields's avatar
      nfsd4: minor NFSv2/v3 write decoding cleanup · 24c3569d
      J. Bruce Fields authored
      [ Upstream commit db44bac4 ]
      
      Use a couple shortcuts that will simplify a following bugfix.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      24c3569d
    • J. Bruce Fields's avatar
      nfsd: check for oversized NFSv2/v3 arguments · c9bb9f02
      J. Bruce Fields authored
      [ Upstream commit e6838a29 ]
      
      A client can append random data to the end of an NFSv2 or NFSv3 RPC call
      without our complaining; we'll just stop parsing at the end of the
      expected data and ignore the rest.
      
      Encoded arguments and replies are stored together in an array of pages,
      and if a call is too large it could leave inadequate space for the
      reply.  This is normally OK because NFS RPC's typically have either
      short arguments and long replies (like READ) or long arguments and short
      replies (like WRITE).  But a client that sends an incorrectly long reply
      can violate those assumptions.  This was observed to cause crashes.
      
      Also, several operations increment rq_next_page in the decode routine
      before checking the argument size, which can leave rq_next_page pointing
      well past the end of the page array, causing trouble later in
      svc_free_pages.
      
      So, following a suggestion from Neil Brown, add a central check to
      enforce our expectation that no NFSv2/v3 call has both a large call and
      a large reply.
      
      As followup we may also want to rewrite the encoding routines to check
      more carefully that they aren't running off the end of the page array.
      
      We may also consider rejecting calls that have any extra garbage
      appended.  That would be safer, and within our rights by spec, but given
      the age of our server and the NFS protocol, and the fact that we've
      never enforced this before, we may need to balance that against the
      possibility of breaking some oddball client.
      Reported-by: default avatarTuomas Haanpää <thaan@synopsys.com>
      Reported-by: default avatarAri Kauppi <ari@synopsys.com>
      Cc: stable@vger.kernel.org
      Reviewed-by: default avatarNeilBrown <neilb@suse.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      c9bb9f02
    • Alexey Brodkin's avatar
      usb: Make sure usb/phy/of gets built-in · 6a5e6149
      Alexey Brodkin authored
      [ Upstream commit 3d615964 ]
      
      DWC3 driver uses of_usb_get_phy_mode() which is
      implemented in drivers/usb/phy/of.c and in bare minimal
      configuration it might not be pulled in kernel binary.
      
      In case of ARC or ARM this could be easily reproduced with
      "allnodefconfig" +CONFIG_USB=m +CONFIG_USB_DWC3=m.
      
      On building all ends-up with:
      ---------------------->8------------------
        Kernel: arch/arm/boot/Image is ready
        Kernel: arch/arm/boot/zImage is ready
        Building modules, stage 2.
        MODPOST 5 modules
      ERROR: "of_usb_get_phy_mode" [drivers/usb/dwc3/dwc3.ko] undefined!
      make[1]: *** [__modpost] Error 1
      make: *** [modules] Error 2
      ---------------------->8------------------
      Signed-off-by: default avatarAlexey Brodkin <abrodkin@synopsys.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
      Cc: Geert Uytterhoeven <geert+renesas@glider.be>
      Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Felipe Balbi <balbi@kernel.org>
      Cc: Felix Fietkau <nbd@nbd.name>
      Cc: Jeremy Kerr <jk@ozlabs.org>
      Cc: linux-snps-arc@lists.infradead.org
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      6a5e6149
    • Takashi Iwai's avatar
      ASoC: intel: Fix PM and non-atomic crash in bytcr drivers · 37232313
      Takashi Iwai authored
      [ Upstream commit 6e4cac23 ]
      
      The FE setups of Intel SST bytcr_rt5640 and bytcr_rt5651 drivers carry
      the ignore_suspend flag, and this prevents the suspend/resume working
      properly while the stream is running, since SST core code has the
      check of the running streams and returns -EBUSY.  Drop these
      superfluous flags for fixing the behavior.
      
      Also, the bytcr_rt5640 driver lacks of nonatomic flag in some FE
      definitions, which leads to the kernel Oops at suspend/resume like:
      
        BUG: scheduling while atomic: systemd-sleep/3144/0x00000003
        Call Trace:
         dump_stack+0x5c/0x7a
         __schedule_bug+0x55/0x70
         __schedule+0x63c/0x8c0
         schedule+0x3d/0x90
         schedule_timeout+0x16b/0x320
         ? del_timer_sync+0x50/0x50
         ? sst_wait_timeout+0xa9/0x170 [snd_intel_sst_core]
         ? sst_wait_timeout+0xa9/0x170 [snd_intel_sst_core]
         ? remove_wait_queue+0x60/0x60
         ? sst_prepare_and_post_msg+0x275/0x960 [snd_intel_sst_core]
         ? sst_pause_stream+0x9b/0x110 [snd_intel_sst_core]
         ....
      
      This patch addresses these appropriately, too.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Acked-by: default avatarVinod Koul <vinod.koul@intel.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Cc: <stable@vger.kernel.org> # v4.1+
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      37232313
    • Dmitry Torokhov's avatar
      Input: i8042 - add Clevo P650RS to the i8042 reset list · b583cc93
      Dmitry Torokhov authored
      [ Upstream commit 7c5bb4ac ]
      
      Clevo P650RS and other similar devices require i8042 to be reset in order
      to detect Synaptics touchpad.
      Reported-by: default avatarPaweł Bylica <chfast@gmail.com>
      Tested-by: default avatarEd Bordin <edbordin@gmail.com>
      Cc: stable@vger.kernel.org
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=190301Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      b583cc93
    • Somasundaram Krishnasamy's avatar
      dm era: save spacemap metadata root after the pre-commit · 56e19170
      Somasundaram Krishnasamy authored
      [ Upstream commit 117aceb0 ]
      
      When committing era metadata to disk, it doesn't always save the latest
      spacemap metadata root in superblock. Due to this, metadata is getting
      corrupted sometimes when reopening the device. The correct order of update
      should be, pre-commit (shadows spacemap root), save the spacemap root
      (newly shadowed block) to in-core superblock and then the final commit.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarSomasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      56e19170