1. 19 Apr, 2019 6 commits
    • zhong jiang's avatar
      mm/memory_hotplug: do not unlock after failing to take the device_hotplug_lock · 37803841
      zhong jiang authored
      When adding memory by probing a memory block in the sysfs interface,
      there is an obvious issue where we will unlock the device_hotplug_lock
      when we failed to takes it.
      
      That issue was introduced in 8df1d0e4 ("mm/memory_hotplug: make
      add_memory() take the device_hotplug_lock").
      
      We should drop out in time when failing to take the device_hotplug_lock.
      
      Link: http://lkml.kernel.org/r/1554696437-9593-1-git-send-email-zhongjiang@huawei.com
      Fixes: 8df1d0e4 ("mm/memory_hotplug: make add_memory() take the device_hotplug_lock")
      Signed-off-by: default avatarzhong jiang <zhongjiang@huawei.com>
      Reported-by: default avatarYang yingliang <yangyingliang@huawei.com>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Reviewed-by: default avatarDavid Hildenbrand <david@redhat.com>
      Reviewed-by: default avatarOscar Salvador <osalvador@suse.de>
      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>
      37803841
    • Hugh Dickins's avatar
      mm: swapoff: shmem_unuse() stop eviction without igrab() · af53d3e9
      Hugh Dickins authored
      The igrab() in shmem_unuse() looks good, but we forgot that it gives no
      protection against concurrent unmounting: a point made by Konstantin
      Khlebnikov eight years ago, and then fixed in 2.6.39 by 778dd893
      ("tmpfs: fix race between umount and swapoff").  The current 5.1-rc
      swapoff is liable to hit "VFS: Busy inodes after unmount of tmpfs.
      Self-destruct in 5 seconds.  Have a nice day..." followed by GPF.
      
      Once again, give up on using igrab(); but don't go back to making such
      heavy-handed use of shmem_swaplist_mutex as last time: that would spoil
      the new design, and I expect could deadlock inside shmem_swapin_page().
      
      Instead, shmem_unuse() just raise a "stop_eviction" count in the shmem-
      specific inode, and shmem_evict_inode() wait for that to go down to 0.
      Call it "stop_eviction" rather than "swapoff_busy" because it can be put
      to use for others later (huge tmpfs patches expect to use it).
      
      That simplifies shmem_unuse(), protecting it from both unlink and
      unmount; and in practice lets it locate all the swap in its first try.
      But do not rely on that: there's still a theoretical case, when
      shmem_writepage() might have been preempted after its get_swap_page(),
      before making the swap entry visible to swapoff.
      
      [hughd@google.com: remove incorrect list_del()]
        Link: http://lkml.kernel.org/r/alpine.LSU.2.11.1904091133570.1898@eggly.anvils
      Link: http://lkml.kernel.org/r/alpine.LSU.2.11.1904081259400.1523@eggly.anvils
      Fixes: b56a2d8a ("mm: rid swapoff of quadratic complexity")
      Signed-off-by: default avatarHugh Dickins <hughd@google.com>
      Cc: "Alex Xu (Hello71)" <alex_y_xu@yahoo.ca>
      Cc: Huang Ying <ying.huang@intel.com>
      Cc: Kelley Nielsen <kelleynnn@gmail.com>
      Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
      Cc: Rik van Riel <riel@surriel.com>
      Cc: Vineeth Pillai <vpillai@digitalocean.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      af53d3e9
    • Hugh Dickins's avatar
      mm: swapoff: take notice of completion sooner · 64165b1a
      Hugh Dickins authored
      The old try_to_unuse() implementation was driven by find_next_to_unuse(),
      which terminated as soon as all the swap had been freed.
      
      Add inuse_pages checks now (alongside signal_pending()) to stop scanning
      mms and swap_map once finished.
      
      The same ought to be done in shmem_unuse() too, but never was before,
      and needs a different interface: so leave it as is for now.
      
      Link: http://lkml.kernel.org/r/alpine.LSU.2.11.1904081258200.1523@eggly.anvils
      Fixes: b56a2d8a ("mm: rid swapoff of quadratic complexity")
      Signed-off-by: default avatarHugh Dickins <hughd@google.com>
      Cc: "Alex Xu (Hello71)" <alex_y_xu@yahoo.ca>
      Cc: Huang Ying <ying.huang@intel.com>
      Cc: Kelley Nielsen <kelleynnn@gmail.com>
      Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
      Cc: Rik van Riel <riel@surriel.com>
      Cc: Vineeth Pillai <vpillai@digitalocean.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      64165b1a
    • Hugh Dickins's avatar
      mm: swapoff: remove too limiting SWAP_UNUSE_MAX_TRIES · dd862deb
      Hugh Dickins authored
      SWAP_UNUSE_MAX_TRIES 3 appeared to work well in earlier testing, but
      further testing has proved it to be a source of unnecessary swapoff
      EBUSY failures (which can then be followed by unmount EBUSY failures).
      
      When mmget_not_zero() or shmem's igrab() fails, there is an mm exiting
      or inode being evicted, freeing up swap independent of try_to_unuse().
      Those typically completed much sooner than the old quadratic swapoff,
      but now it's more common that swapoff may need to wait for them.
      
      It's possible to move those cases from init_mm.mmlist and shmem_swaplist
      to separate "exiting" swaplists, and try_to_unuse() then wait for those
      lists to be emptied; but we've not bothered with that in the past, and
      don't want to risk missing some other forgotten case.  So just revert to
      cycling around until the swap is gone, without any retries limit.
      
      Link: http://lkml.kernel.org/r/alpine.LSU.2.11.1904081256170.1523@eggly.anvils
      Fixes: b56a2d8a ("mm: rid swapoff of quadratic complexity")
      Signed-off-by: default avatarHugh Dickins <hughd@google.com>
      Cc: "Alex Xu (Hello71)" <alex_y_xu@yahoo.ca>
      Cc: Huang Ying <ying.huang@intel.com>
      Cc: Kelley Nielsen <kelleynnn@gmail.com>
      Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
      Cc: Rik van Riel <riel@surriel.com>
      Cc: Vineeth Pillai <vpillai@digitalocean.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      dd862deb
    • Hugh Dickins's avatar
      mm: swapoff: shmem_find_swap_entries() filter out other types · 87039546
      Hugh Dickins authored
      Swapfile "type" was passed all the way down to shmem_unuse_inode(), but
      then forgotten from shmem_find_swap_entries(): with the result that
      removing one swapfile would try to free up all the swap from shmem - no
      problem when only one swapfile anyway, but counter-productive when more,
      causing swapoff to be unnecessarily OOM-killed when it should succeed.
      
      Link: http://lkml.kernel.org/r/alpine.LSU.2.11.1904081254470.1523@eggly.anvils
      Fixes: b56a2d8a ("mm: rid swapoff of quadratic complexity")
      Signed-off-by: default avatarHugh Dickins <hughd@google.com>
      Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
      Cc: "Alex Xu (Hello71)" <alex_y_xu@yahoo.ca>
      Cc: Vineeth Pillai <vpillai@digitalocean.com>
      Cc: Kelley Nielsen <kelleynnn@gmail.com>
      Cc: Rik van Riel <riel@surriel.com>
      Cc: Huang Ying <ying.huang@intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      87039546
    • Qian Cai's avatar
      slab: store tagged freelist for off-slab slabmgmt · 1a62b18d
      Qian Cai authored
      Commit 51dedad0 ("kasan, slab: make freelist stored without tags")
      calls kasan_reset_tag() for off-slab slab management object leading to
      freelist being stored non-tagged.
      
      However, cache_grow_begin() calls alloc_slabmgmt() which calls
      kmem_cache_alloc_node() assigns a tag for the address and stores it in
      the shadow address.  As the result, it causes endless errors below
      during boot due to drain_freelist() -> slab_destroy() ->
      kasan_slab_free() which compares already untagged freelist against the
      stored tag in the shadow address.
      
      Since off-slab slab management object freelist is such a special case,
      just store it tagged.  Non-off-slab management object freelist is still
      stored untagged which has not been assigned a tag and should not cause
      any other troubles with this inconsistency.
      
        BUG: KASAN: double-free or invalid-free in slab_destroy+0x84/0x88
        Pointer tag: [ff], memory tag: [99]
      
        CPU: 0 PID: 1376 Comm: kworker/0:4 Tainted: G        W 5.1.0-rc3+ #8
        Hardware name: HPE Apollo 70             /C01_APACHE_MB         , BIOS L50_5.13_1.0.6 07/10/2018
        Workqueue: cgroup_destroy css_killed_work_fn
        Call trace:
         print_address_description+0x74/0x2a4
         kasan_report_invalid_free+0x80/0xc0
         __kasan_slab_free+0x204/0x208
         kasan_slab_free+0xc/0x18
         kmem_cache_free+0xe4/0x254
         slab_destroy+0x84/0x88
         drain_freelist+0xd0/0x104
         __kmem_cache_shrink+0x1ac/0x224
         __kmemcg_cache_deactivate+0x1c/0x28
         memcg_deactivate_kmem_caches+0xa0/0xe8
         memcg_offline_kmem+0x8c/0x3d4
         mem_cgroup_css_offline+0x24c/0x290
         css_killed_work_fn+0x154/0x618
         process_one_work+0x9cc/0x183c
         worker_thread+0x9b0/0xe38
         kthread+0x374/0x390
         ret_from_fork+0x10/0x18
      
        Allocated by task 1625:
         __kasan_kmalloc+0x168/0x240
         kasan_slab_alloc+0x18/0x20
         kmem_cache_alloc_node+0x1f8/0x3a0
         cache_grow_begin+0x4fc/0xa24
         cache_alloc_refill+0x2f8/0x3e8
         kmem_cache_alloc+0x1bc/0x3bc
         sock_alloc_inode+0x58/0x334
         alloc_inode+0xb8/0x164
         new_inode_pseudo+0x20/0xec
         sock_alloc+0x74/0x284
         __sock_create+0xb0/0x58c
         sock_create+0x98/0xb8
         __sys_socket+0x60/0x138
         __arm64_sys_socket+0xa4/0x110
         el0_svc_handler+0x2c0/0x47c
         el0_svc+0x8/0xc
      
        Freed by task 1625:
         __kasan_slab_free+0x114/0x208
         kasan_slab_free+0xc/0x18
         kfree+0x1a8/0x1e0
         single_release+0x7c/0x9c
         close_pdeo+0x13c/0x43c
         proc_reg_release+0xec/0x108
         __fput+0x2f8/0x784
         ____fput+0x1c/0x28
         task_work_run+0xc0/0x1b0
         do_notify_resume+0xb44/0x1278
         work_pending+0x8/0x10
      
        The buggy address belongs to the object at ffff809681b89e00
         which belongs to the cache kmalloc-128 of size 128
        The buggy address is located 0 bytes inside of
         128-byte region [ffff809681b89e00, ffff809681b89e80)
        The buggy address belongs to the page:
        page:ffff7fe025a06e00 count:1 mapcount:0 mapping:01ff80082000fb00
        index:0xffff809681b8fe04
        flags: 0x17ffffffc000200(slab)
        raw: 017ffffffc000200 ffff7fe025a06d08 ffff7fe022ef7b88 01ff80082000fb00
        raw: ffff809681b8fe04 ffff809681b80000 00000001000000e0 0000000000000000
        page dumped because: kasan: bad access detected
        page allocated via order 0, migratetype Unmovable, gfp_mask
        0x2420c0(__GFP_IO|__GFP_FS|__GFP_NOWARN|__GFP_COMP|__GFP_THISNODE)
         prep_new_page+0x4e0/0x5e0
         get_page_from_freelist+0x4ce8/0x50d4
         __alloc_pages_nodemask+0x738/0x38b8
         cache_grow_begin+0xd8/0xa24
         ____cache_alloc_node+0x14c/0x268
         __kmalloc+0x1c8/0x3fc
         ftrace_free_mem+0x408/0x1284
         ftrace_free_init_mem+0x20/0x28
         kernel_init+0x24/0x548
         ret_from_fork+0x10/0x18
      
        Memory state around the buggy address:
         ffff809681b89c00: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe
         ffff809681b89d00: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe
        >ffff809681b89e00: 99 99 99 99 99 99 99 99 fe fe fe fe fe fe fe fe
                           ^
         ffff809681b89f00: 43 43 43 43 43 fe fe fe fe fe fe fe fe fe fe fe
         ffff809681b8a000: 6d fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe
      
      Link: http://lkml.kernel.org/r/20190403022858.97584-1-cai@lca.pw
      Fixes: 51dedad0 ("kasan, slab: make freelist stored without tags")
      Signed-off-by: default avatarQian Cai <cai@lca.pw>
      Reviewed-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
      Cc: Alexander Potapenko <glider@google.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      1a62b18d
  2. 18 Apr, 2019 7 commits
    • Linus Torvalds's avatar
      Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux · 6d906f99
      Linus Torvalds authored
      Pull arm64 fix from Catalin Marinas:
       "Avoid compiler uninitialised warning introduced by recent arm64 futex
        fix"
      
      * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
        arm64: futex: Restore oldval initialization to work around buggy compilers
      6d906f99
    • Nathan Chancellor's avatar
      arm64: futex: Restore oldval initialization to work around buggy compilers · ff8acf92
      Nathan Chancellor authored
      Commit 045afc24 ("arm64: futex: Fix FUTEX_WAKE_OP atomic ops with
      non-zero result value") removed oldval's zero initialization in
      arch_futex_atomic_op_inuser because it is not necessary. Unfortunately,
      Android's arm64 GCC 4.9.4 [1] does not agree:
      
      ../kernel/futex.c: In function 'do_futex':
      ../kernel/futex.c:1658:17: warning: 'oldval' may be used uninitialized
      in this function [-Wmaybe-uninitialized]
         return oldval == cmparg;
                       ^
      In file included from ../kernel/futex.c:73:0:
      ../arch/arm64/include/asm/futex.h:53:6: note: 'oldval' was declared here
        int oldval, ret, tmp;
            ^
      
      GCC fails to follow that when ret is non-zero, futex_atomic_op_inuser
      returns right away, avoiding the uninitialized use that it claims.
      Restoring the zero initialization works around this issue.
      
      [1]: https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-4.9/
      
      Cc: stable@vger.kernel.org
      Fixes: 045afc24 ("arm64: futex: Fix FUTEX_WAKE_OP atomic ops with non-zero result value")
      Reviewed-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      ff8acf92
    • Christian Brauner's avatar
      signal: use fdget() since we don't allow O_PATH · 738a7832
      Christian Brauner authored
      As stated in the original commit for pidfd_send_signal() we don't allow
      to signal processes through O_PATH file descriptors since it is
      semantically equivalent to a write on the pidfd.
      
      We already correctly error out right now and return EBADF if an O_PATH
      fd is passed.  This is because we use file->f_op to detect whether a
      pidfd is passed and O_PATH fds have their file->f_op set to empty_fops
      in do_dentry_open() and thus fail the test.
      
      Thus, there is no regression.  It's just semantically correct to use
      fdget() and return an error right from there instead of taking a
      reference and returning an error later.
      Signed-off-by: default avatarChristian Brauner <christian@brauner.io>
      Acked-by: default avatarOleg Nesterov <oleg@redhat.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Jann Horn <jann@thejh.net>
      Cc: David Howells <dhowells@redhat.com>
      Cc: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
      Cc: Andy Lutomirsky <luto@kernel.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Aleksa Sarai <cyphar@cyphar.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      738a7832
    • Linus Torvalds's avatar
      Merge tag 's390-5.1-3' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux · d22113a2
      Linus Torvalds authored
      Pull s390 bug fixes from Martin Schwidefsky:
      
       - Fix overwrite of the initial ramdisk due to misuse of IS_ENABLED
      
       - Fix integer overflow in the dasd driver resulting in incorrect number
         of blocks for large devices
      
       - Fix a lockdep false positive in the 3270 driver
      
       - Fix a deadlock in the zcrypt driver
      
       - Fix incorrect debug feature entries in the pkey api
      
       - Fix inline assembly constraints fallout with CONFIG_KASAN=y
      
      * tag 's390-5.1-3' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
        s390: correct some inline assembly constraints
        s390/pkey: add one more argument space for debug feature entry
        s390/zcrypt: fix possible deadlock situation on ap queue remove
        s390/3270: fix lockdep false positive on view->lock
        s390/dasd: Fix capacity calculation for large volumes
        s390/mem_detect: Use IS_ENABLED(CONFIG_BLK_DEV_INITRD)
      d22113a2
    • Linus Torvalds's avatar
      Merge tag 'afs-fixes-20190413' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs · 2a852fd1
      Linus Torvalds authored
      Pull AFS fixes from David Howells:
      
       - Stop using the deprecated get_seconds().
      
       - Don't make tracepoint strings const as the section they go in isn't
         read-only.
      
       - Differentiate failure due to unmarshalling from other failure cases.
         We shouldn't abort with RXGEN_CC/SS_UNMARSHAL if it's not due to
         unmarshalling.
      
       - Add a missing unlock_page().
      
       - Fix the interaction between receiving a notification from a server
         that it has invalidated all outstanding callback promises and a
         client call that we're in the middle of making that will get a new
         promise.
      
      * tag 'afs-fixes-20190413' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs:
        afs: Fix in-progess ops to ignore server-level callback invalidation
        afs: Unlock pages for __pagevec_release()
        afs: Differentiate abort due to unmarshalling from other errors
        afs: Avoid section confusion in CM_NAME
        afs: avoid deprecated get_seconds()
      2a852fd1
    • Linus Torvalds's avatar
      Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 · d3ce3b18
      Linus Torvalds authored
      Pull crypto fix from Herbert Xu:
       "Fix a bug in the implementation of the x86 accelerated version of
        poly1305"
      
      * 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
        crypto: x86/poly1305 - fix overflow during partial reduction
      d3ce3b18
    • Linus Torvalds's avatar
      Merge tag 'drm-fixes-2019-04-18' of git://anongit.freedesktop.org/drm/drm · 95ea5529
      Linus Torvalds authored
      Pull drm fixes from Dave Airlie:
       "Since Easter is looming for me, I'm just pushing whatever is in my
        tree, I'll see what else turns up and maybe I'll send another pull
        early next week if there is anything.
      
        tegra:
         - stream id programming fix
         - avoid divide by 0 for bad hdmi audio setup code
      
        ttm:
         - Hugepages fix
         - refcount imbalance in error path fix
      
        amdgpu:
         - GPU VM fixes for Vega/RV
         - DC AUX fix for active DP-DVI dongles
         - DC fix for multihead regression"
      
      * tag 'drm-fixes-2019-04-18' of git://anongit.freedesktop.org/drm/drm:
        drm/tegra: hdmi: Setup audio only if configured
        drm/amd/display: If one stream full updates, full update all planes
        drm/amdgpu/gmc9: fix VM_L2_CNTL3 programming
        drm/amdgpu: shadow in shadow_list without tbo.mem.start cause page fault in sriov TDR
        gpu: host1x: Program stream ID to bypass without SMMU
        drm/amd/display: extending AUX SW Timeout
        drm/ttm: fix dma_fence refcount imbalance on error path
        drm/ttm: fix incrementing the page pointer for huge pages
        drm/ttm: fix start page for huge page check in ttm_put_pages()
        drm/ttm: fix out-of-bounds read in ttm_put_pages() v2
      95ea5529
  3. 17 Apr, 2019 20 commits
  4. 16 Apr, 2019 7 commits
    • Tony Camuso's avatar
      ipmi: ipmi_si_hardcode.c: init si_type array to fix a crash · a885bcfd
      Tony Camuso authored
      The intended behavior of function ipmi_hardcode_init_one() is to default
      to kcs interface when no type argument is presented when initializing
      ipmi with hard coded addresses.
      
      However, the array of char pointers allocated on the stack by function
      ipmi_hardcode_init() was not inited to zeroes, so it contained stack
      debris.
      
      Consequently, passing the cruft stored in this array to function
      ipmi_hardcode_init_one() caused a crash when it was unable to detect
      that the char * being passed was nonsense and tried to access the
      address specified by the bogus pointer.
      
      The fix is simply to initialize the si_type array to zeroes, so if
      there were no type argument given to at the command line, function
      ipmi_hardcode_init_one() could properly default to the kcs interface.
      Signed-off-by: default avatarTony Camuso <tcamuso@redhat.com>
      Message-Id: <1554837603-40299-1-git-send-email-tcamuso@redhat.com>
      Signed-off-by: default avatarCorey Minyard <cminyard@mvista.com>
      a885bcfd
    • Corey Minyard's avatar
      ipmi: Fix failure on SMBIOS specified devices · bd2e98b3
      Corey Minyard authored
      An extra memset was put into a place that cleared the interface
      type.
      Reported-by: default avatarTony Camuso <tcamuso@redhat.com>
      Fixes: 3cd83bac ("ipmi: Consolidate the adding of platform devices")
      Signed-off-by: default avatarCorey Minyard <cminyard@mvista.com>
      bd2e98b3
    • Linus Torvalds's avatar
      Merge tag 'riscv-for-linus-5.1-rc6' of... · 444fe991
      Linus Torvalds authored
      Merge tag 'riscv-for-linus-5.1-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/palmer/riscv-linux
      
      Pull RISC-V fixes from Palmer Dabbelt:
       "This contains an assortment of RISC-V-related fixups that we found
        after rc4. They're all really unrelated:
      
         - The addition of a 32-bit defconfig, to emphasize testing the 32-bit
           port.
      
         - A device tree bindings patch, which is pre-work for some patches
           that target 5.2.
      
         - A fix to support booting on systems with more physical memory than
           the maximum supported by the kernel"
      
      * tag 'riscv-for-linus-5.1-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/palmer/riscv-linux:
        RISC-V: Fix Maximum Physical Memory 2GiB option for 64bit systems
        dt-bindings: clock: sifive: add FU540-C000 PRCI clock constants
        RISC-V: Add separate defconfig for 32bit systems
      444fe991
    • Linus Torvalds's avatar
      Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm · b5de3c50
      Linus Torvalds authored
      Pull KVM fixes from Paolo Bonzini:
       "5.1 keeps its reputation as a big bugfix release for KVM x86.
      
         - Fix for a memory leak introduced during the merge window
      
         - Fixes for nested VMX with ept=0
      
         - Fixes for AMD (APIC virtualization, NMI injection)
      
         - Fixes for Hyper-V under KVM and KVM under Hyper-V
      
         - Fixes for 32-bit SMM and tests for SMM virtualization
      
         - More array_index_nospec peppering"
      
      * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: (21 commits)
        KVM: x86: avoid misreporting level-triggered irqs as edge-triggered in tracing
        KVM: fix spectrev1 gadgets
        KVM: x86: fix warning Using plain integer as NULL pointer
        selftests: kvm: add a selftest for SMM
        selftests: kvm: fix for compilers that do not support -no-pie
        selftests: kvm/evmcs_test: complete I/O before migrating guest state
        KVM: x86: Always use 32-bit SMRAM save state for 32-bit kernels
        KVM: x86: Don't clear EFER during SMM transitions for 32-bit vCPU
        KVM: x86: clear SMM flags before loading state while leaving SMM
        KVM: x86: Open code kvm_set_hflags
        KVM: x86: Load SMRAM in a single shot when leaving SMM
        KVM: nVMX: Expose RDPMC-exiting only when guest supports PMU
        KVM: x86: Raise #GP when guest vCPU do not support PMU
        x86/kvm: move kvm_load/put_guest_xcr0 into atomic context
        KVM: x86: svm: make sure NMI is injected after nmi_singlestep
        svm/avic: Fix invalidate logical APIC id entry
        Revert "svm: Fix AVIC incomplete IPI emulation"
        kvm: mmu: Fix overflow on kvm mmu page limit calculation
        KVM: nVMX: always use early vmcs check when EPT is disabled
        KVM: nVMX: allow tests to use bad virtual-APIC page address
        ...
      b5de3c50
    • Aurelien Aptel's avatar
      CIFS: keep FileInfo handle live during oplock break · b98749ca
      Aurelien Aptel authored
      In the oplock break handler, writing pending changes from pages puts
      the FileInfo handle. If the refcount reaches zero it closes the handle
      and waits for any oplock break handler to return, thus causing a deadlock.
      
      To prevent this situation:
      
      * We add a wait flag to cifsFileInfo_put() to decide whether we should
        wait for running/pending oplock break handlers
      
      * We keep an additionnal reference of the SMB FileInfo handle so that
        for the rest of the handler putting the handle won't close it.
        - The ref is bumped everytime we queue the handler via the
          cifs_queue_oplock_break() helper.
        - The ref is decremented at the end of the handler
      
      This bug was triggered by xfstest 464.
      
      Also important fix to address the various reports of
      oops in smb2_push_mandatory_locks
      Signed-off-by: default avatarAurelien Aptel <aaptel@suse.com>
      Signed-off-by: default avatarSteve French <stfrench@microsoft.com>
      Reviewed-by: default avatarPavel Shilovsky <pshilov@microsoft.com>
      CC: Stable <stable@vger.kernel.org>
      b98749ca
    • Ronnie Sahlberg's avatar
      cifs: fix handle leak in smb2_query_symlink() · e6d0fb7b
      Ronnie Sahlberg authored
      If we enter smb2_query_symlink() for something that is not a symlink
      and where the SMB2_open() would succeed we would never end up
      closing this handle and would thus leak a handle on the server.
      
      Fix this by immediately calling SMB2_close() on successfull open.
      Signed-off-by: default avatarRonnie Sahlberg <lsahlber@redhat.com>
      CC: Stable <stable@vger.kernel.org>
      Signed-off-by: default avatarSteve French <stfrench@microsoft.com>
      Reviewed-by: default avatarPavel Shilovsky <pshilov@microsoft.com>
      e6d0fb7b
    • ZhangXiaoxu's avatar
      cifs: Fix lease buffer length error · b57a55e2
      ZhangXiaoxu authored
      There is a KASAN slab-out-of-bounds:
      BUG: KASAN: slab-out-of-bounds in _copy_from_iter_full+0x783/0xaa0
      Read of size 80 at addr ffff88810c35e180 by task mount.cifs/539
      
      CPU: 1 PID: 539 Comm: mount.cifs Not tainted 4.19 #10
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
                  rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org 04/01/2014
      Call Trace:
       dump_stack+0xdd/0x12a
       print_address_description+0xa7/0x540
       kasan_report+0x1ff/0x550
       check_memory_region+0x2f1/0x310
       memcpy+0x2f/0x80
       _copy_from_iter_full+0x783/0xaa0
       tcp_sendmsg_locked+0x1840/0x4140
       tcp_sendmsg+0x37/0x60
       inet_sendmsg+0x18c/0x490
       sock_sendmsg+0xae/0x130
       smb_send_kvec+0x29c/0x520
       __smb_send_rqst+0x3ef/0xc60
       smb_send_rqst+0x25a/0x2e0
       compound_send_recv+0x9e8/0x2af0
       cifs_send_recv+0x24/0x30
       SMB2_open+0x35e/0x1620
       open_shroot+0x27b/0x490
       smb2_open_op_close+0x4e1/0x590
       smb2_query_path_info+0x2ac/0x650
       cifs_get_inode_info+0x1058/0x28f0
       cifs_root_iget+0x3bb/0xf80
       cifs_smb3_do_mount+0xe00/0x14c0
       cifs_do_mount+0x15/0x20
       mount_fs+0x5e/0x290
       vfs_kern_mount+0x88/0x460
       do_mount+0x398/0x31e0
       ksys_mount+0xc6/0x150
       __x64_sys_mount+0xea/0x190
       do_syscall_64+0x122/0x590
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      It can be reproduced by the following step:
        1. samba configured with: server max protocol = SMB2_10
        2. mount -o vers=default
      
      When parse the mount version parameter, the 'ops' and 'vals'
      was setted to smb30,  if negotiate result is smb21, just
      update the 'ops' to smb21, but the 'vals' is still smb30.
      When add lease context, the iov_base is allocated with smb21
      ops, but the iov_len is initiallited with the smb30. Because
      the iov_len is longer than iov_base, when send the message,
      copy array out of bounds.
      
      we need to keep the 'ops' and 'vals' consistent.
      
      Fixes: 9764c02f ("SMB3: Add support for multidialect negotiate (SMB2.1 and later)")
      Fixes: d5c7076b ("smb3: add smb3.1.1 to default dialect list")
      Signed-off-by: default avatarZhangXiaoxu <zhangxiaoxu5@huawei.com>
      Signed-off-by: default avatarSteve French <stfrench@microsoft.com>
      CC: Stable <stable@vger.kernel.org>
      Reviewed-by: default avatarPavel Shilovsky <pshilov@microsoft.com>
      b57a55e2