1. 20 May, 2017 37 commits
    • Steve French's avatar
      SMB3: Work around mount failure when using SMB3 dialect to Macs · b85fa412
      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 avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b85fa412
    • Steve French's avatar
      Set unicode flag on cifs echo request to avoid Mac error · 89d23005
      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 avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      89d23005
    • Andrey Ryabinin's avatar
      fs/block_dev: always invalidate cleancache in invalidate_bdev() · 7aad381a
      Andrey Ryabinin authored
      commit a5f6a6a9 upstream.
      
      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>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7aad381a
    • Luis Henriques's avatar
      ceph: fix memory leak in __ceph_setxattr() · bb7031c7
      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 avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bb7031c7
    • Michal Hocko's avatar
      fs/xattr.c: zero out memory copied to userspace in getxattr · eb04a734
      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>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      eb04a734
    • Eric Biggers's avatar
      ext4: evict inline data when writing to memory map · a3e6be0e
      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>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a3e6be0e
    • Jack Morgenstein's avatar
      IB/mlx4: Reduce SRIOV multicast cleanup warning message to debug level · ab7ebca4
      Jack Morgenstein authored
      commit fb7a9174 upstream.
      
      A warning message during SRIOV multicast cleanup should have actually been
      a debug level message. The condition generating the warning does no harm
      and can fill the message log.
      
      In some cases, during testing, some tests were so intense as to swamp the
      message log with these warning messages, causing a stall in the console
      message log output task. This stall caused an NMI to be sent to all CPUs
      (so that they all dumped their stacks into the message log).
      Aside from the message flood causing an NMI, the tests all passed.
      
      Once the message flood which caused the NMI is removed (by reducing the
      warning message to debug level), the NMI no longer occurs.
      
      Sample message log (console log) output illustrating the flood and
      resultant NMI (snippets with comments and modified with ... instead
      of hex digits, to satisfy checkpatch.pl):
      
       <mlx4_ib> _mlx4_ib_mcg_port_cleanup: ... WARNING: group refcount 1!!!...
       *** About 4000 almost identical lines in less than one second ***
       <mlx4_ib> _mlx4_ib_mcg_port_cleanup: ... WARNING: group refcount 1!!!...
       INFO: rcu_sched detected stalls on CPUs/tasks: { 17} (...)
       *** { 17} above indicates that CPU 17 was the one that stalled ***
       sending NMI to all CPUs:
       ...
       NMI backtrace for cpu 17
       CPU: 17 PID: 45909 Comm: kworker/17:2
       Hardware name: HP ProLiant DL360p Gen8, BIOS P71 09/08/2013
       Workqueue: events fb_flashcursor
       task: ffff880478...... ti: ffff88064e...... task.ti: ffff88064e......
       RIP: 0010:[ffffffff81......]  [ffffffff81......] io_serial_in+0x15/0x20
       RSP: 0018:ffff88064e257cb0  EFLAGS: 00000002
       RAX: 0000000000...... RBX: ffffffff81...... RCX: 0000000000......
       RDX: 0000000000...... RSI: 0000000000...... RDI: ffffffff81......
       RBP: ffff88064e...... R08: ffffffff81...... R09: 0000000000......
       R10: 0000000000...... R11: ffff88064e...... R12: 0000000000......
       R13: 0000000000...... R14: ffffffff81...... R15: 0000000000......
       FS:  0000000000......(0000) GS:ffff8804af......(0000) knlGS:000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080......
       CR2: 00007f2a2f...... CR3: 0000000001...... CR4: 0000000000......
       DR0: 0000000000...... DR1: 0000000000...... DR2: 0000000000......
       DR3: 0000000000...... DR6: 00000000ff...... DR7: 0000000000......
       Stack:
       ffff88064e...... ffffffff81...... ffffffff81...... 0000000000......
       ffffffff81...... ffff88064e...... ffffffff81...... ffffffff81......
       ffffffff81...... ffff88064e...... ffffffff81...... 0000000000......
       Call Trace:
      [<ffffffff813d099b>] wait_for_xmitr+0x3b/0xa0
      [<ffffffff813d0b5c>] serial8250_console_putchar+0x1c/0x30
      [<ffffffff813d0b40>] ? serial8250_console_write+0x140/0x140
      [<ffffffff813cb5fa>] uart_console_write+0x3a/0x80
      [<ffffffff813d0aae>] serial8250_console_write+0xae/0x140
      [<ffffffff8107c4d1>] call_console_drivers.constprop.15+0x91/0xf0
      [<ffffffff8107d6cf>] console_unlock+0x3bf/0x400
      [<ffffffff813503cd>] fb_flashcursor+0x5d/0x140
      [<ffffffff81355c30>] ? bit_clear+0x120/0x120
      [<ffffffff8109d5fb>] process_one_work+0x17b/0x470
      [<ffffffff8109e3cb>] worker_thread+0x11b/0x400
      [<ffffffff8109e2b0>] ? rescuer_thread+0x400/0x400
      [<ffffffff810a5aef>] kthread+0xcf/0xe0
      [<ffffffff810a5a20>] ? kthread_create_on_node+0x140/0x140
      [<ffffffff81645858>] ret_from_fork+0x58/0x90
      [<ffffffff810a5a20>] ? kthread_create_on_node+0x140/0x140
      Code: 48 89 e5 d3 e6 48 63 f6 48 03 77 10 8b 06 5d c3 66 0f 1f 44 00 00 66 66 66 6
      
      As indicated in the stack trace above, the console output task got swamped.
      
      Fixes: b9c5d6a6 ("IB/mlx4: Add multicast group (MCG) paravirtualization for SR-IOV")
      Signed-off-by: default avatarJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: default avatarLeon Romanovsky <leon@kernel.org>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ab7ebca4
    • Jack Morgenstein's avatar
      IB/mlx4: Fix ib device initialization error flow · 1ad689bd
      Jack Morgenstein authored
      commit 99e68909 upstream.
      
      In mlx4_ib_add, procedure mlx4_ib_alloc_eqs is called to allocate EQs.
      
      However, in the mlx4_ib_add error flow, procedure mlx4_ib_free_eqs is not
      called to free the allocated EQs.
      
      Fixes: e605b743 ("IB/mlx4: Increase the number of vectors (EQs) available for ULPs")
      Signed-off-by: default avatarJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: default avatarLeon Romanovsky <leon@kernel.org>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1ad689bd
    • Shamir Rabinovitch's avatar
      IB/IPoIB: ibX: failed to create mcg debug file · 1360f430
      Shamir Rabinovitch authored
      commit 771a5258 upstream.
      
      When udev renames the netdev devices, ipoib debugfs entries does not
      get renamed. As a result, if subsequent probe of ipoib device reuse the
      name then creating a debugfs entry for the new device would fail.
      
      Also, moved ipoib_create_debug_files and ipoib_delete_debug_files as part
      of ipoib event handling in order to avoid any race condition between these.
      
      Fixes: 1732b0ef ([IPoIB] add path record information in debugfs)
      Signed-off-by: default avatarVijay Kumar <vijay.ac.kumar@oracle.com>
      Signed-off-by: default avatarShamir Rabinovitch <shamir.rabinovitch@oracle.com>
      Reviewed-by: default avatarMark Bloch <markb@mellanox.com>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1360f430
    • Jack Morgenstein's avatar
      IB/core: Fix sysfs registration error flow · 1549c883
      Jack Morgenstein authored
      commit b312be3d upstream.
      
      The kernel commit cited below restructured ib device management
      so that the device kobject is initialized in ib_alloc_device.
      
      As part of the restructuring, the kobject is now initialized in
      procedure ib_alloc_device, and is later added to the device hierarchy
      in the ib_register_device call stack, in procedure
      ib_device_register_sysfs (which calls device_add).
      
      However, in the ib_device_register_sysfs error flow, if an error
      occurs following the call to device_add, the cleanup procedure
      device_unregister is called. This call results in the device object
      being deleted -- which results in various use-after-free crashes.
      
      The correct cleanup call is device_del -- which undoes device_add
      without deleting the device object.
      
      The device object will then (correctly) be deleted in the
      ib_register_device caller's error cleanup flow, when the caller invokes
      ib_dealloc_device.
      
      Fixes: 55aeed06 ("IB/core: Make ib_alloc_device init the kobject")
      Signed-off-by: default avatarJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: default avatarLeon Romanovsky <leon@kernel.org>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1549c883
    • Alex Williamson's avatar
      vfio/type1: Remove locked page accounting workqueue · d96bb545
      Alex Williamson authored
      commit 0cfef2b7 upstream.
      
      If the mmap_sem is contented then the vfio type1 IOMMU backend will
      defer locked page accounting updates to a workqueue task.  This has a
      few problems and depending on which side the user tries to play, they
      might be over-penalized for unmaps that haven't yet been accounted or
      race the workqueue to enter more mappings than they're allowed.  The
      original intent of this workqueue mechanism seems to be focused on
      reducing latency through the ioctl, but we cannot do so at the cost
      of correctness.  Remove this workqueue mechanism and update the
      callers to allow for failure.  We can also now recheck the limit under
      write lock to make sure we don't exceed it.
      
      vfio_pin_pages_remote() also now necessarily includes an unwind path
      which we can jump to directly if the consecutive page pinning finds
      that we're exceeding the user's memory limits.  This avoids the
      current lazy approach which does accounting and mapping up to the
      fault, only to return an error on the next iteration to unwind the
      entire vfio_dma.
      
      Cc: stable@vger.kernel.org
      Reviewed-by: default avatarPeter Xu <peterx@redhat.com>
      Reviewed-by: default avatarKirti Wankhede <kwankhede@nvidia.com>
      Signed-off-by: default avatarAlex Williamson <alex.williamson@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      d96bb545
    • Somasundaram Krishnasamy's avatar
      dm era: save spacemap metadata root after the pre-commit · 341adf51
      Somasundaram Krishnasamy authored
      commit 117aceb0 upstream.
      
      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.
      Signed-off-by: default avatarSomasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      341adf51
    • Stephan Mueller's avatar
      crypto: algif_aead - Require setkey before accept(2) · dcd4004a
      Stephan Mueller authored
      commit 2a2a251f upstream.
      
      Some cipher implementations will crash if you try to use them
      without calling setkey first.  This patch adds a check so that
      the accept(2) call will fail with -ENOKEY if setkey hasn't been
      done on the socket yet.
      
      Fixes: 400c40cf ("crypto: algif - add AEAD support")
      Signed-off-by: default avatarStephan Mueller <smueller@chronox.de>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dcd4004a
    • Mike Snitzer's avatar
      block: fix blk_integrity_register to use template's interval_exp if not 0 · 21cb4dc5
      Mike Snitzer authored
      commit 2859323e upstream.
      
      When registering an integrity profile: if the template's interval_exp is
      not 0 use it, otherwise use the ilog2() of logical block size of the
      provided gendisk.
      
      This fixes a long-standing DM linear target bug where it cannot pass
      integrity data to the underlying device if its logical block size
      conflicts with the underlying device's logical block size.
      Reported-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Acked-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      21cb4dc5
    • Andrew Jones's avatar
      KVM: arm/arm64: fix races in kvm_psci_vcpu_on · cbaeca82
      Andrew Jones authored
      commit 6c7a5dce upstream.
      
      Fix potential races in kvm_psci_vcpu_on() by taking the kvm->lock
      mutex.  In general, it's a bad idea to allow more than one PSCI_CPU_ON
      to process the same target VCPU at the same time.  One such problem
      that may arise is that one PSCI_CPU_ON could be resetting the target
      vcpu, which fills the entire sys_regs array with a temporary value
      including the MPIDR register, while another looks up the VCPU based
      on the MPIDR value, resulting in no target VCPU found.  Resolves both
      races found with the kvm-unit-tests/arm/psci unit test.
      Reviewed-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Reviewed-by: default avatarChristoffer Dall <cdall@linaro.org>
      Reported-by: default avatarLevente Kurusa <lkurusa@redhat.com>
      Suggested-by: default avatarChristoffer Dall <cdall@linaro.org>
      Signed-off-by: default avatarAndrew Jones <drjones@redhat.com>
      Signed-off-by: default avatarChristoffer Dall <cdall@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cbaeca82
    • David Hildenbrand's avatar
      KVM: x86: fix user triggerable warning in kvm_apic_accept_events() · 7b268351
      David Hildenbrand authored
      commit 28bf2888 upstream.
      
      If we already entered/are about to enter SMM, don't allow switching to
      INIT/SIPI_RECEIVED, otherwise the next call to kvm_apic_accept_events()
      will report a warning.
      
      Same applies if we are already in MP state INIT_RECEIVED and SMM is
      requested to be turned on. Refuse to set the VCPU events in this case.
      
      Fixes: cd7764fe ("KVM: x86: latch INITs while in system management mode")
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarDavid Hildenbrand <david@redhat.com>
      Signed-off-by: default avatarRadim Krčmář <rkrcmar@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7b268351
    • Richard Weinberger's avatar
      um: Fix PTRACE_POKEUSER on x86_64 · a2d5dcf3
      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 avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a2d5dcf3
    • Ben Hutchings's avatar
      x86, pmem: Fix cache flushing for iovec write < 8 bytes · b8cd9dd5
      Ben Hutchings authored
      commit 8376efd3 upstream.
      
      Commit 11e63f6d added cache flushing for unaligned writes from an
      iovec, covering the first and last cache line of a >= 8 byte write and
      the first cache line of a < 8 byte write.  But an unaligned write of
      2-7 bytes can still cover two cache lines, so make sure we flush both
      in that case.
      
      Fixes: 11e63f6d ("x86, pmem: fix broken __copy_user_nocache ...")
      Signed-off-by: default avatarBen Hutchings <ben.hutchings@codethink.co.uk>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b8cd9dd5
    • Andy Lutomirski's avatar
      selftests/x86/ldt_gdt_32: Work around a glibc sigaction() bug · d34ecdc9
      Andy Lutomirski authored
      commit 65973dd3 upstream.
      
      i386 glibc is buggy and calls the sigaction syscall incorrectly.
      
      This is asymptomatic for normal programs, but it blows up on
      programs that do evil things with segmentation.  The ldt_gdt
      self-test is an example of such an evil program.
      
      This doesn't appear to be a regression -- I think I just got lucky
      with the uninitialized memory that glibc threw at the kernel when I
      wrote the test.
      
      This hackish fix manually issues sigaction(2) syscalls to undo the
      damage.  Without the fix, ldt_gdt_32 segfaults; with the fix, it
      passes for me.
      
      See: https://sourceware.org/bugzilla/show_bug.cgi?id=21269Signed-off-by: default avatarAndy Lutomirski <luto@kernel.org>
      Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Garnier <thgarnie@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/aaab0f9f93c9af25396f01232608c163a760a668.1490218061.git.luto@kernel.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d34ecdc9
    • Ashish Kalra's avatar
      x86/boot: Fix BSS corruption/overwrite bug in early x86 kernel startup · e89233f5
      Ashish Kalra authored
      commit d594aa02 upstream.
      
      The minimum size for a new stack (512 bytes) setup for arch/x86/boot components
      when the bootloader does not setup/provide a stack for the early boot components
      is not "enough".
      
      The setup code executing as part of early kernel startup code, uses the stack
      beyond 512 bytes and accidentally overwrites and corrupts part of the BSS
      section. This is exposed mostly in the early video setup code, where
      it was corrupting BSS variables like force_x, force_y, which in-turn affected
      kernel parameters such as screen_info (screen_info.orig_video_cols) and
      later caused an exception/panic in console_init().
      
      Most recent boot loaders setup the stack for early boot components, so this
      stack overwriting into BSS section issue has not been exposed.
      Signed-off-by: default avatarAshish Kalra <ashish@bluestacks.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/20170419152015.10011-1-ashishkalra@Ashishs-MacBook-Pro.localSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e89233f5
    • Guenter Roeck's avatar
      usb: hub: Do not attempt to autosuspend disconnected devices · 3d3ca81d
      Guenter Roeck authored
      commit f5cccf49 upstream.
      
      While running a bind/unbind stress test with the dwc3 usb driver on rk3399,
      the following crash was observed.
      
      Unable to handle kernel NULL pointer dereference at virtual address 00000218
      pgd = ffffffc00165f000
      [00000218] *pgd=000000000174f003, *pud=000000000174f003,
      				*pmd=0000000001750003, *pte=00e8000001751713
      Internal error: Oops: 96000005 [#1] PREEMPT SMP
      Modules linked in: uinput uvcvideo videobuf2_vmalloc cmac
      ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat rfcomm
      xt_mark fuse bridge stp llc zram btusb btrtl btbcm btintel bluetooth
      ip6table_filter mwifiex_pcie mwifiex cfg80211 cdc_ether usbnet r8152 mii joydev
      snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device ppp_async
      ppp_generic slhc tun
      CPU: 1 PID: 29814 Comm: kworker/1:1 Not tainted 4.4.52 #507
      Hardware name: Google Kevin (DT)
      Workqueue: pm pm_runtime_work
      task: ffffffc0ac540000 ti: ffffffc0af4d4000 task.ti: ffffffc0af4d4000
      PC is at autosuspend_check+0x74/0x174
      LR is at autosuspend_check+0x70/0x174
      ...
      Call trace:
      [<ffffffc00080dcc0>] autosuspend_check+0x74/0x174
      [<ffffffc000810500>] usb_runtime_idle+0x20/0x40
      [<ffffffc000785ae0>] __rpm_callback+0x48/0x7c
      [<ffffffc000786af0>] rpm_idle+0x1e8/0x498
      [<ffffffc000787cdc>] pm_runtime_work+0x88/0xcc
      [<ffffffc000249bb8>] process_one_work+0x390/0x6b8
      [<ffffffc00024abcc>] worker_thread+0x480/0x610
      [<ffffffc000251a80>] kthread+0x164/0x178
      [<ffffffc0002045d0>] ret_from_fork+0x10/0x40
      
      Source:
      
      (gdb) l *0xffffffc00080dcc0
      0xffffffc00080dcc0 is in autosuspend_check
      (drivers/usb/core/driver.c:1778).
      1773		/* We don't need to check interfaces that are
      1774		 * disabled for runtime PM.  Either they are unbound
      1775		 * or else their drivers don't support autosuspend
      1776		 * and so they are permanently active.
      1777		 */
      1778		if (intf->dev.power.disable_depth)
      1779			continue;
      1780		if (atomic_read(&intf->dev.power.usage_count) > 0)
      1781			return -EBUSY;
      1782		w |= intf->needs_remote_wakeup;
      
      Code analysis shows that intf is set to NULL in usb_disable_device() prior
      to setting actconfig to NULL. At the same time, usb_runtime_idle() does not
      lock the usb device, and neither does any of the functions in the
      traceback. This means that there is no protection against a race condition
      where usb_disable_device() is removing dev->actconfig->interface[] pointers
      while those are being accessed from autosuspend_check().
      
      To solve the problem, synchronize and validate device state between
      autosuspend_check() and usb_disconnect().
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3d3ca81d
    • Guenter Roeck's avatar
      usb: hub: Fix error loop seen after hub communication errors · 0b4dad7c
      Guenter Roeck authored
      commit 245b2eec upstream.
      
      While stress testing a usb controller using a bind/unbind looop, the
      following error loop was observed.
      
      usb 7-1.2: new low-speed USB device number 3 using xhci-hcd
      usb 7-1.2: hub failed to enable device, error -108
      usb 7-1-port2: cannot disable (err = -22)
      usb 7-1-port2: couldn't allocate usb_device
      usb 7-1-port2: cannot disable (err = -22)
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: activate --> -22
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: activate --> -22
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: activate --> -22
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: activate --> -22
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: activate --> -22
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: activate --> -22
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: activate --> -22
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: activate --> -22
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      ** 57 printk messages dropped ** hub 7-1:1.0: activate --> -22
      ** 82 printk messages dropped ** hub 7-1:1.0: hub_ext_port_status failed (err = -22)
      
      This continues forever. After adding tracebacks into the code,
      the call sequence leading to this is found to be as follows.
      
      [<ffffffc0007fc8e0>] hub_activate+0x368/0x7b8
      [<ffffffc0007fceb4>] hub_resume+0x2c/0x3c
      [<ffffffc00080b3b8>] usb_resume_interface.isra.6+0x128/0x158
      [<ffffffc00080b5d0>] usb_suspend_both+0x1e8/0x288
      [<ffffffc00080c9c4>] usb_runtime_suspend+0x3c/0x98
      [<ffffffc0007820a0>] __rpm_callback+0x48/0x7c
      [<ffffffc00078217c>] rpm_callback+0xa8/0xd4
      [<ffffffc000786234>] rpm_suspend+0x84/0x758
      [<ffffffc000786ca4>] rpm_idle+0x2c8/0x498
      [<ffffffc000786ed4>] __pm_runtime_idle+0x60/0xac
      [<ffffffc00080eba8>] usb_autopm_put_interface+0x6c/0x7c
      [<ffffffc000803798>] hub_event+0x10ac/0x12ac
      [<ffffffc000249bb8>] process_one_work+0x390/0x6b8
      [<ffffffc00024abcc>] worker_thread+0x480/0x610
      [<ffffffc000251a80>] kthread+0x164/0x178
      [<ffffffc0002045d0>] ret_from_fork+0x10/0x40
      
      kick_hub_wq() is called from hub_activate() even after failures to
      communicate with the hub. This results in an endless sequence of
      hub event -> hub activate -> wq trigger -> hub event -> ...
      
      Provide two solutions for the problem.
      
      - Only trigger the hub event queue if communication with the hub
        is successful.
      - After a suspend failure, only resume already suspended interfaces
        if the communication with the device is still possible.
      
      Each of the changes fixes the observed problem. Use both to improve
      robustness.
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0b4dad7c
    • Alexey Brodkin's avatar
      usb: Make sure usb/phy/of gets built-in · 7cad8a47
      Alexey Brodkin authored
      commit 3d615964 upstream.
      
      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
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7cad8a47
    • Gustavo A. R. Silva's avatar
      usb: misc: add missing continue in switch · 6c3785cc
      Gustavo A. R. Silva authored
      commit 2c930e3d upstream.
      
      Add missing continue in switch.
      
      Addresses-Coverity-ID: 1248733
      Signed-off-by: default avatarGustavo A. R. Silva <garsilva@embeddedor.com>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6c3785cc
    • Ian Abbott's avatar
      staging: comedi: jr3_pci: cope with jiffies wraparound · d3c04901
      Ian Abbott authored
      commit 8ec04a49 upstream.
      
      The timer expiry routine `jr3_pci_poll_dev()` checks for expiry by
      checking whether the absolute value of `jiffies` (stored in local
      variable `now`) is greater than the expected expiry time in jiffy units.
      This will fail when `jiffies` wraps around.  Also, it seems to make
      sense to handle the expiry one jiffy earlier than the current test.  Use
      `time_after_eq()` to check for expiry.
      Signed-off-by: default avatarIan Abbott <abbotti@mev.co.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d3c04901
    • Ian Abbott's avatar
      staging: comedi: jr3_pci: fix possible null pointer dereference · 7fc6659b
      Ian Abbott authored
      commit 45292be0 upstream.
      
      For some reason, the driver does not consider allocation of the
      subdevice private data to be a fatal error when attaching the COMEDI
      device.  It tests the subdevice private data pointer for validity at
      certain points, but omits some crucial tests.  In particular,
      `jr3_pci_auto_attach()` calls `jr3_pci_alloc_spriv()` to allocate and
      initialize the subdevice private data, but the same function
      subsequently dereferences the pointer to access the `next_time_min` and
      `next_time_max` members without checking it first.  The other missing
      test is in the timer expiry routine `jr3_pci_poll_dev()`, but it will
      crash before it gets that far.
      
      Fix the bug by returning `-ENOMEM` from `jr3_pci_auto_attach()` as soon
      as one of the calls to `jr3_pci_alloc_spriv()` returns `NULL`.  The
      COMEDI core will subsequently call `jr3_pci_detach()` to clean up.
      Signed-off-by: default avatarIan Abbott <abbotti@mev.co.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7fc6659b
    • Johan Hovold's avatar
      staging: gdm724x: gdm_mux: fix use-after-free on module unload · 5ac489a8
      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>
      5ac489a8
    • Malcolm Priestley's avatar
      staging: vt6656: use off stack for out buffer USB transfers. · 265500bf
      Malcolm Priestley authored
      commit 12ecd24e upstream.
      
      Since 4.9 mandated USB buffers be heap allocated this causes the driver
      to fail.
      
      Since there is a wide range of buffer sizes use kmemdup to create
      allocated buffer.
      Signed-off-by: default avatarMalcolm Priestley <tvboxspy@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      265500bf
    • Malcolm Priestley's avatar
      staging: vt6656: use off stack for in buffer USB transfers. · 9d3c4578
      Malcolm Priestley authored
      commit 05c0cf88 upstream.
      
      Since 4.9 mandated USB buffers to be heap allocated. This causes
      the driver to fail.
      
      Create buffer for USB transfers.
      Signed-off-by: default avatarMalcolm Priestley <tvboxspy@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9d3c4578
    • Ajay Kaher's avatar
      USB: Proper handling of Race Condition when two USB class drivers try to call... · de9d2d29
      Ajay Kaher authored
      USB: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously
      
      commit 2f86a96b upstream.
      
      There is race condition when two USB class drivers try to call
      init_usb_class at the same time and leads to crash.
      code path: probe->usb_register_dev->init_usb_class
      
      To solve this, mutex locking has been added in init_usb_class() and
      destroy_usb_class().
      
      As pointed by Alan, removed "if (usb_class)" test from destroy_usb_class()
      because usb_class can never be NULL there.
      Signed-off-by: default avatarAjay Kaher <ajay.kaher@samsung.com>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      de9d2d29
    • Marek Vasut's avatar
      USB: serial: ftdi_sio: add device ID for Microsemi/Arrow SF2PLUS Dev Kit · fcd9a083
      Marek Vasut authored
      commit 31c5d192 upstream.
      
      This development kit has an FT4232 on it with a custom USB VID/PID.
      The FT4232 provides four UARTs, but only two are used. The UART 0
      is used by the FlashPro5 programmer and UART 2 is connected to the
      SmartFusion2 CortexM3 SoC UART port.
      
      Note that the USB VID is registered to Actel according to Linux USB
      VID database, but that was acquired by Microsemi.
      Signed-off-by: default avatarMarek Vasut <marex@denx.de>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fcd9a083
    • Peter Chen's avatar
      usb: host: xhci: print correct command ring address · af3c8bf0
      Peter Chen authored
      commit 6fc091fb upstream.
      
      Print correct command ring address using 'val_64'.
      Signed-off-by: default avatarPeter Chen <peter.chen@nxp.com>
      Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      af3c8bf0
    • Nicholas Bellinger's avatar
      iscsi-target: Set session_fall_back_to_erl0 when forcing reinstatement · 8e1a740a
      Nicholas Bellinger authored
      commit 197b806a upstream.
      
      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>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8e1a740a
    • Nicholas Bellinger's avatar
      target: Convert ACL change queue_depth se_session reference usage · 6cd0200a
      Nicholas Bellinger authored
      commit d36ad77f upstream.
      
      This patch converts core_tpg_set_initiator_node_queue_depth()
      to use struct se_node_acl->acl_sess_list when performing
      explicit se_tpg_tfo->shutdown_session() for active sessions,
      in order for new se_node_acl->queue_depth to take effect.
      
      This follows how core_tpg_del_initiator_node_acl() currently
      works when invoking se_tpg_tfo->shutdown-session(), and ahead
      of the next patch to take se_node_acl->acl_kref during lookup,
      the extra get_initiator_node_acl() can go away. In order to
      achieve this, go ahead and change target_get_session() to use
      kref_get_unless_zero() and propigate up the return value
      to know when a session is already being released.
      
      This is because se_node_acl->acl_group is already protecting
      se_node_acl->acl_group reference via configfs, and shutdown
      within core_tpg_del_initiator_node_acl() won't occur until
      sys_write() to core_tpg_set_initiator_node_queue_depth()
      attribute returns back to user-space.
      
      Also, drop the left-over iscsi-target hack, and obtain
      se_portal_group->session_lock in lio_tpg_shutdown_session()
      internally. Remove iscsi-target wrapper and unused se_tpg +
      force parameters and associated code.
      Reported-by: default avatarChristoph Hellwig <hch@lst.de>
      Cc: Sagi Grimberg <sagig@mellanox.com>
      Cc: Hannes Reinecke <hare@suse.de>
      Cc: Andy Grover <agrover@redhat.com>
      Cc: Mike Christie <michaelc@cs.wisc.edu>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6cd0200a
    • Bart Van Assche's avatar
      target/fileio: Fix zero-length READ and WRITE handling · de41b0e1
      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 avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      de41b0e1
    • Nicholas Bellinger's avatar
      target: Fix compare_and_write_callback handling for non GOOD status · a1c2b01c
      Nicholas Bellinger authored
      commit a71a5dc7 upstream.
      
      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>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a1c2b01c
    • Juergen Gross's avatar
      xen: adjust early dom0 p2m handling to xen hypervisor behavior · 8e209a07
      Juergen Gross authored
      commit 69861e0a upstream.
      
      When booted as pv-guest the p2m list presented by the Xen is already
      mapped to virtual addresses. In dom0 case the hypervisor might make use
      of 2M- or 1G-pages for this mapping. Unfortunately while being properly
      aligned in virtual and machine address space, those pages might not be
      aligned properly in guest physical address space.
      
      So when trying to obtain the guest physical address of such a page
      pud_pfn() and pmd_pfn() must be avoided as those will mask away guest
      physical address bits not being zero in this special case.
      Signed-off-by: default avatarJuergen Gross <jgross@suse.com>
      Reviewed-by: default avatarJan Beulich <jbeulich@suse.com>
      Signed-off-by: default avatarJuergen Gross <jgross@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8e209a07
  2. 14 May, 2017 3 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.4.68 · be90e260
      Greg Kroah-Hartman authored
      be90e260
    • Ilya Dryomov's avatar
      block: get rid of blk_integrity_revalidate() · 4a4c6a08
      Ilya Dryomov authored
      commit 19b7ccf8 upstream.
      
      Commit 25520d55 ("block: Inline blk_integrity in struct gendisk")
      introduced blk_integrity_revalidate(), which seems to assume ownership
      of the stable pages flag and unilaterally clears it if no blk_integrity
      profile is registered:
      
          if (bi->profile)
                  disk->queue->backing_dev_info->capabilities |=
                          BDI_CAP_STABLE_WRITES;
          else
                  disk->queue->backing_dev_info->capabilities &=
                          ~BDI_CAP_STABLE_WRITES;
      
      It's called from revalidate_disk() and rescan_partitions(), making it
      impossible to enable stable pages for drivers that support partitions
      and don't use blk_integrity: while the call in revalidate_disk() can be
      trivially worked around (see zram, which doesn't support partitions and
      hence gets away with zram_revalidate_disk()), rescan_partitions() can
      be triggered from userspace at any time.  This breaks rbd, where the
      ceph messenger is responsible for generating/verifying CRCs.
      
      Since blk_integrity_{un,}register() "must" be used for (un)registering
      the integrity profile with the block layer, move BDI_CAP_STABLE_WRITES
      setting there.  This way drivers that call blk_integrity_register() and
      use integrity infrastructure won't interfere with drivers that don't
      but still want stable pages.
      
      Fixes: 25520d55 ("block: Inline blk_integrity in struct gendisk")
      Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Mike Snitzer <snitzer@redhat.com>
      Tested-by: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarIlya Dryomov <idryomov@gmail.com>
      [idryomov@gmail.com: backport to < 4.11: bdi is embedded in queue]
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4a4c6a08
    • Nicolai Hähnle's avatar
      drm/ttm: fix use-after-free races in vm fault handling · 60e3f5a9
      Nicolai Hähnle authored
      commit 3089c1df upstream.
      
      The vm fault handler relies on the fact that the VMA owns a reference
      to the BO. However, once mmap_sem is released, other tasks are free to
      destroy the VMA, which can lead to the BO being freed. Fix two code
      paths where that can happen, both related to vm fault retries.
      
      Found via a lock debugging warning which flagged &bo->wu_mutex as
      locked while being destroyed.
      
      Fixes: cbe12e74 ("drm/ttm: Allow vm fault retries")
      Signed-off-by: default avatarNicolai Hähnle <nicolai.haehnle@amd.com>
      Reviewed-by: default avatarChristian König <christian.koenig@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      60e3f5a9