1. 29 May, 2020 14 commits
  2. 28 May, 2020 17 commits
  3. 27 May, 2020 9 commits
    • Aric Cyr's avatar
      drm/amd/display: Fix potential integer wraparound resulting in a hang · 4e518320
      Aric Cyr authored
      [Why]
      If VUPDATE_END is before VUPDATE_START the delay calculated can become
      very large, causing a soft hang.
      
      [How]
      Take the absolute value of the difference between START and END.
      Signed-off-by: default avatarAric Cyr <aric.cyr@amd.com>
      Reviewed-by: default avatarNicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
      Acked-by: default avatarQingqing Zhuo <qingqing.zhuo@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Cc: stable@vger.kernel.org
      4e518320
    • Simon Ser's avatar
      drm/amd/display: drop cursor position check in atomic test · f7d5991b
      Simon Ser authored
      get_cursor_position already handles the case where the cursor has
      negative off-screen coordinates by not setting
      dc_cursor_position.enabled.
      Signed-off-by: default avatarSimon Ser <contact@emersion.fr>
      Fixes: 626bf90f ("drm/amd/display: add basic atomic check for cursor plane")
      Cc: Alex Deucher <alexander.deucher@amd.com>
      Cc: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Cc: stable@vger.kernel.org
      f7d5991b
    • Dongli Zhang's avatar
      nvme-pci: avoid race between nvme_reap_pending_cqes() and nvme_poll() · 9210c075
      Dongli Zhang authored
      There may be a race between nvme_reap_pending_cqes() and nvme_poll(), e.g.,
      when doing live reset while polling the nvme device.
      
            CPU X                        CPU Y
                                     nvme_poll()
      nvme_dev_disable()
      -> nvme_stop_queues()
      -> nvme_suspend_io_queues()
      -> nvme_suspend_queue()
                                     -> spin_lock(&nvmeq->cq_poll_lock);
      -> nvme_reap_pending_cqes()
         -> nvme_process_cq()        -> nvme_process_cq()
      
      In the above scenario, the nvme_process_cq() for the same queue may be
      running on both CPU X and CPU Y concurrently.
      
      It is much more easier to reproduce the issue when CONFIG_PREEMPT is
      enabled in kernel. When CONFIG_PREEMPT is disabled, it would take longer
      time for nvme_stop_queues()-->blk_mq_quiesce_queue() to wait for grace
      period.
      
      This patch protects nvme_process_cq() with nvmeq->cq_poll_lock in
      nvme_reap_pending_cqes().
      
      Fixes: fa46c6fb ("nvme/pci: move cqe check after device shutdown")
      Signed-off-by: default avatarDongli Zhang <dongli.zhang@oracle.com>
      Reviewed-by: default avatarMing Lei <ming.lei@redhat.com>
      Reviewed-by: default avatarKeith Busch <kbusch@kernel.org>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      9210c075
    • Linus Torvalds's avatar
      Merge tag 'fsnotify_for_v5.7-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs · b0c3ba31
      Linus Torvalds authored
      Pull fanotify FAN_DIR_MODIFY disabling from Jan Kara:
       "A single patch that disables FAN_DIR_MODIFY support that was merged in
        this merge window.
      
        When discussing further functionality we realized it may be more
        logical to guard it with a feature flag or to call things slightly
        differently (or maybe not) so let's not set the API in stone for now."
      
      * tag 'fsnotify_for_v5.7-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs:
        fanotify: turn off support for FAN_DIR_MODIFY
      b0c3ba31
    • Linus Torvalds's avatar
      Merge branch 'for-5.7-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup · 3301f6ae
      Linus Torvalds authored
      Pull cgroup fixes from Tejun Heo:
      
       - Reverted stricter synchronization for cgroup recursive stats which
         was prepping it for event counter usage which never got merged. The
         change was causing performation regressions in some cases.
      
       - Restore bpf-based device-cgroup operation even when cgroup1 device
         cgroup is disabled.
      
       - An out-param init fix.
      
      * 'for-5.7-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup:
        device_cgroup: Cleanup cgroup eBPF device filter code
        xattr: fix uninitialized out-param
        Revert "cgroup: Add memory barriers to plug cgroup_rstat_updated() race window"
      3301f6ae
    • Jason Gunthorpe's avatar
      RDMA/core: Fix double destruction of uobject · c85f4abe
      Jason Gunthorpe authored
      Fix use after free when user user space request uobject concurrently for
      the same object, within the RCU grace period.
      
      In that case, remove_handle_idr_uobject() is called twice and we will have
      an extra put on the uobject which cause use after free.  Fix it by leaving
      the uobject write locked after it was removed from the idr.
      
      Call to rdma_lookup_put_uobject with UVERBS_LOOKUP_DESTROY instead of
      UVERBS_LOOKUP_WRITE will do the work.
      
        refcount_t: underflow; use-after-free.
        WARNING: CPU: 0 PID: 1381 at lib/refcount.c:28 refcount_warn_saturate+0xfe/0x1a0
        Kernel panic - not syncing: panic_on_warn set ...
        CPU: 0 PID: 1381 Comm: syz-executor.0 Not tainted 5.5.0-rc3 #8
        Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
        Call Trace:
         dump_stack+0x94/0xce
         panic+0x234/0x56f
         __warn+0x1cc/0x1e1
         report_bug+0x200/0x310
         fixup_bug.part.11+0x32/0x80
         do_error_trap+0xd3/0x100
         do_invalid_op+0x31/0x40
         invalid_op+0x1e/0x30
        RIP: 0010:refcount_warn_saturate+0xfe/0x1a0
        Code: 0f 0b eb 9b e8 23 f6 6d ff 80 3d 6c d4 19 03 00 75 8d e8 15 f6 6d ff 48 c7 c7 c0 02 55 bd c6 05 57 d4 19 03 01 e8 a2 58 49 ff <0f> 0b e9 6e ff ff ff e8 f6 f5 6d ff 80 3d 42 d4 19 03 00 0f 85 5c
        RSP: 0018:ffffc90002df7b98 EFLAGS: 00010282
        RAX: 0000000000000000 RBX: ffff88810f6a193c RCX: ffffffffba649009
        RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffff88811b0283cc
        RBP: 0000000000000003 R08: ffffed10236060e3 R09: ffffed10236060e3
        R10: 0000000000000001 R11: ffffed10236060e2 R12: ffff88810f6a193c
        R13: ffffc90002df7d60 R14: 0000000000000000 R15: ffff888116ae6a08
         uverbs_uobject_put+0xfd/0x140
         __uobj_perform_destroy+0x3d/0x60
         ib_uverbs_close_xrcd+0x148/0x170
         ib_uverbs_write+0xaa5/0xdf0
         __vfs_write+0x7c/0x100
         vfs_write+0x168/0x4a0
         ksys_write+0xc8/0x200
         do_syscall_64+0x9c/0x390
         entry_SYSCALL_64_after_hwframe+0x44/0xa9
        RIP: 0033:0x465b49
        Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
        RSP: 002b:00007f759d122c58 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
        RAX: ffffffffffffffda RBX: 000000000073bfa8 RCX: 0000000000465b49
        RDX: 000000000000000c RSI: 0000000020000080 RDI: 0000000000000003
        RBP: 0000000000000003 R08: 0000000000000000 R09: 0000000000000000
        R10: 0000000000000000 R11: 0000000000000246 R12: 00007f759d1236bc
        R13: 00000000004ca27c R14: 000000000070de40 R15: 00000000ffffffff
        Dumping ftrace buffer:
           (ftrace buffer empty)
        Kernel Offset: 0x39400000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
      
      Fixes: 7452a3c7 ("IB/uverbs: Allow RDMA_REMOVE_DESTROY to work concurrently with disassociate")
      Link: https://lore.kernel.org/r/20200527135534.482279-1-leon@kernel.orgSigned-off-by: default avatarMaor Gottlieb <maorg@mellanox.com>
      Signed-off-by: default avatarLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      c85f4abe
    • Amir Goldstein's avatar
      fanotify: turn off support for FAN_DIR_MODIFY · f1793699
      Amir Goldstein authored
      FAN_DIR_MODIFY has been enabled by commit 44d705b0 ("fanotify:
      report name info for FAN_DIR_MODIFY event") in 5.7-rc1. Now we are
      planning further extensions to the fanotify API and during that we
      realized that FAN_DIR_MODIFY may behave slightly differently to be more
      consistent with extensions we plan. So until we finalize these
      extensions, let's not bind our hands with exposing FAN_DIR_MODIFY to
      userland.
      Signed-off-by: default avatarAmir Goldstein <amir73il@gmail.com>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      f1793699
    • Linus Torvalds's avatar
      Merge branch 'exec-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace · 006f38a1
      Linus Torvalds authored
      Pull execve fix from Eric Biederman:
       "While working on my exec cleanups I found a bug in exec that winds up
        miscomputing the ambient credentials during exec. Andy appears to have
        to been confused as to why credentials are computed for both the
        script and the interpreter
      
        From the original patch description:
      
         [3] Linux very confusingly processes both the script and the
             interpreter if applicable, for reasons that elude me. The results
             from thinking about a script's file capabilities and/or setuid
             bits are mostly discarded.
      
        The only value in struct cred that gets changed in cap_bprm_set_creds
        that I could find that might persist between the script and the
        interpreter was cap_ambient. Which is fixed with this trivial change"
      
      * 'exec-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace:
        exec: Always set cap_ambient in cap_bprm_set_creds
      006f38a1
    • Krzysztof Kozlowski's avatar
      x86: Hide the archdata.iommu field behind generic IOMMU_API · ed3119e4
      Krzysztof Kozlowski authored
      There is a generic, kernel wide configuration symbol for enabling the
      IOMMU specific bits: CONFIG_IOMMU_API.  Implementations (including
      INTEL_IOMMU and AMD_IOMMU driver) select it so use it here as well.
      
      This makes the conditional archdata.iommu field consistent with other
      platforms and also fixes any compile test builds of other IOMMU drivers,
      when INTEL_IOMMU or AMD_IOMMU are not selected).
      
      For the case when INTEL_IOMMU/AMD_IOMMU and COMPILE_TEST are not
      selected, this should create functionally equivalent code/choice.  With
      COMPILE_TEST this field could appear if other IOMMU drivers are chosen
      but neither INTEL_IOMMU nor AMD_IOMMU are not.
      Reported-by: default avatarkbuild test robot <lkp@intel.com>
      Fixes: e93a1695 ("iommu: Enable compile testing for some of drivers")
      Signed-off-by: default avatarKrzysztof Kozlowski <krzk@kernel.org>
      Acked-by: default avatarBorislav Petkov <bp@suse.de>
      Link: https://lore.kernel.org/r/20200518120855.27822-2-krzk@kernel.orgSigned-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      ed3119e4