1. 19 Oct, 2021 21 commits
    • Joey Gouly's avatar
      WIP: convert inline asm to named operands · 88b42a00
      Joey Gouly authored
      
      
      Signed-off-by: Joey Gouly's avatarJoey Gouly <joey.gouly@arm.com>
      88b42a00
    • Linus Torvalds's avatar
      Merge branch 'akpm' (patches from Andrew) · d9abdee5
      Linus Torvalds authored
      Merge misc fixes from Andrew Morton:
       "19 patches.
      
        Subsystems affected by this patch series: mm (userfaultfd, migration,
        memblock, mempolicy, slub, secretmem, and thp), ocfs2, binfmt, vfs,
        and misc"
      
      * emailed patches from Andrew Morton <akpm@linux-foundation.org>:
        mailmap: add Andrej Shadura
        mm/thp: decrease nr_thps in file's mapping on THP split
        mm/secretmem: fix NULL page->mapping dereference in page_is_secretmem()
        vfs: check fd has read access in kernel_read_file_from_fd()
        elfcore: correct reference to CONFIG_UML
        mm, slub: fix incorrect memcg slab count for bulk free
        mm, slub: fix potential use-after-free in slab_debugfs_fops
        mm, slub: fix potential memoryleak in kmem_cache_open()
        mm, slub: fix mismatch between reconstructed freelist depth and cnt
        mm, slub: fix two bugs in slab_debug_trace_open()
        mm/mempolicy: do not allow illegal MPOL_F_NUMA_BALANCING | MPOL_LOCAL in mbind()
        memblock: check memory total_size
        ocfs2: mount fails with buffer overflow in strlen
        ocfs2: fix data corruption after conversion from inline format
        mm/migrate: fix CPUHP state to update node demotion order
        mm/migrate: add CPU hotplug to demotion #ifdef
        mm/migrate: optimize hotplug-time demotion order updates
        userfaultfd: fix a race between writeprotect and exit_mmap()
        mm/userfaultfd: selftests: fix memory corruption with thp enabled
      d9abdee5
    • Andrej Shadura's avatar
      mailmap: add Andrej Shadura · 362d5dfc
      Andrej Shadura authored
      Add a mapping for my old work email for BelDisplayTech to the personal
      email, and make sure the Collabora email has the correct spelling of the
      first name.
      
      Link: https://lkml.kernel.org/r/20210917091016.30232-1-andrew.shadura@collabora.co.uk
      
      
      Signed-off-by: default avatarAndrej Shadura <andrew.shadura@collabora.co.uk>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      362d5dfc
    • Marek Szyprowski's avatar
      mm/thp: decrease nr_thps in file's mapping on THP split · 1ca7554d
      Marek Szyprowski authored
      Decrease nr_thps counter in file's mapping to ensure that the page cache
      won't be dropped excessively on file write access if page has been
      already split.
      
      I've tried a test scenario running a big binary, kernel remaps it with
      THPs, then force a THP split with /sys/kernel/debug/split_huge_pages.
      During any further open of that binary with O_RDWR or O_WRITEONLY kernel
      drops page cache for it, because of non-zero thps counter.
      
      Link: https://lkml.kernel.org/r/20211012120237.2600-1-m.szyprowski@samsung.com
      
      
      Signed-off-by: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
      Fixes: 09d91cda ("mm,thp: avoid writes to file with THP in pagecache")
      Fixes: 06d3eff6
      
       ("mm/thp: fix node page state in split_huge_page_to_list()")
      Acked-by: default avatarMatthew Wilcox (Oracle) <willy@infradead.org>
      Reviewed-by: default avatarYang Shi <shy828301@gmail.com>
      Cc: <sfoon.kim@samsung.com>
      Cc: Song Liu <songliubraving@fb.com>
      Cc: Rik van Riel <riel@surriel.com>
      Cc: "Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: Hillf Danton <hdanton@sina.com>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: William Kucharski <william.kucharski@oracle.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      1ca7554d
    • Sean Christopherson's avatar
      mm/secretmem: fix NULL page->mapping dereference in page_is_secretmem() · 79f9bc58
      Sean Christopherson authored
      Check for a NULL page->mapping before dereferencing the mapping in
      page_is_secretmem(), as the page's mapping can be nullified while gup()
      is running, e.g.  by reclaim or truncation.
      
        BUG: kernel NULL pointer dereference, address: 0000000000000068
        #PF: supervisor read access in kernel mode
        #PF: error_code(0x0000) - not-present page
        PGD 0 P4D 0
        Oops: 0000 [#1] PREEMPT SMP NOPTI
        CPU: 6 PID: 4173897 Comm: CPU 3/KVM Tainted: G        W
        RIP: 0010:internal_get_user_pages_fast+0x621/0x9d0
        Code: <48> 81 7a 68 80 08 04 bc 0f 85 21 ff ff 8 89 c7 be
        RSP: 0018:ffffaa90087679b0 EFLAGS: 00010046
        RAX: ffffe3f37905b900 RBX: 00007f2dd561e000 RCX: ffffe3f37905b934
        RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffe3f37905b900
        ...
        CR2: 0000000000000068 CR3: 00000004c5898003 CR4: 00000000001726e0
        Call Trace:
         get_user_pages_fast_only+0x13/0x20
         hva_to_pfn+0xa9/0x3e0
         try_async_pf+0xa1/0x270
         direct_page_fault+0x113/0xad0
         kvm_mmu_page_fault+0x69/0x680
         vmx_handle_exit+0xe1/0x5d0
         kvm_arch_vcpu_ioctl_run+0xd81/0x1c70
         kvm_vcpu_ioctl+0x267/0x670
         __x64_sys_ioctl+0x83/0xa0
         do_syscall_64+0x56/0x80
         entry_SYSCALL_64_after_hwframe+0x44/0xae
      
      Link: https://lkml.kernel.org/r/20211007231502.3552715-1-seanjc@google.com
      Fixes: 1507f512
      
       ("mm: introduce memfd_secret system call to create "secret" memory areas")
      Signed-off-by: default avatarSean Christopherson <seanjc@google.com>
      Reported-by: default avatarDarrick J. Wong <djwong@kernel.org>
      Reported-by: default avatarStephen <stephenackerman16@gmail.com>
      Tested-by: default avatarDarrick J. Wong <djwong@kernel.org>
      Reviewed-by: default avatarDavid Hildenbrand <david@redhat.com>
      Reviewed-by: default avatarMike Rapoport <rppt@linux.ibm.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      79f9bc58
    • Matthew Wilcox (Oracle)'s avatar
      vfs: check fd has read access in kernel_read_file_from_fd() · 032146cd
      Matthew Wilcox (Oracle) authored
      If we open a file without read access and then pass the fd to a syscall
      whose implementation calls kernel_read_file_from_fd(), we get a warning
      from __kernel_read():
      
              if (WARN_ON_ONCE(!(file->f_mode & FMODE_READ)))
      
      This currently affects both finit_module() and kexec_file_load(), but it
      could affect other syscalls in the future.
      
      Link: https://lkml.kernel.org/r/20211007220110.600005-1-willy@infradead.org
      Fixes: b844f0ec
      
       ("vfs: define kernel_copy_file_from_fd()")
      Signed-off-by: default avatarMatthew Wilcox (Oracle) <willy@infradead.org>
      Reported-by: default avatarHao Sun <sunhao.th@gmail.com>
      Reviewed-by: default avatarKees Cook <keescook@chromium.org>
      Acked-by: default avatarChristian Brauner <christian.brauner@ubuntu.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Mimi Zohar <zohar@linux.ibm.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      032146cd
    • Lukas Bulwahn's avatar
      elfcore: correct reference to CONFIG_UML · b0e90128
      Lukas Bulwahn authored
      Commit 6e7b64b9 ("elfcore: fix building with clang") introduces
      special handling for two architectures, ia64 and User Mode Linux.
      However, the wrong name, i.e., CONFIG_UM, for the intended Kconfig
      symbol for User-Mode Linux was used.
      
      Although the directory for User Mode Linux is ./arch/um; the Kconfig
      symbol for this architecture is called CONFIG_UML.
      
      Luckily, ./scripts/checkkconfigsymbols.py warns on non-existing configs:
      
        UM
        Referencing files: include/linux/elfcore.h
        Similar symbols: UML, NUMA
      
      Correct the name of the config to the intended one.
      
      [akpm@linux-foundation.org: fix um/x86_64, per Catalin]
        Link: https://lkml.kernel.org/r/20211006181119.2851441-1-catalin.marinas@arm.com
        Link: https://lkml.kernel.org/r/YV6pejGzLy5ppEpt@arm.com
      
      Link: https://lkml.kernel.org/r/20211006082209.417-1-lukas.bulwahn@gmail.com
      Fixes: 6e7b64b9
      
       ("elfcore: fix building with clang")
      Signed-off-by: default avatarLukas Bulwahn <lukas.bulwahn@gmail.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Nathan Chancellor <nathan@kernel.org>
      Cc: Nick Desaulniers <ndesaulniers@google.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Barret Rhoden <brho@google.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b0e90128
    • Miaohe Lin's avatar
      mm, slub: fix incorrect memcg slab count for bulk free · 3ddd6026
      Miaohe Lin authored
      kmem_cache_free_bulk() will call memcg_slab_free_hook() for all objects
      when doing bulk free.  So we shouldn't call memcg_slab_free_hook() again
      for bulk free to avoid incorrect memcg slab count.
      
      Link: https://lkml.kernel.org/r/20210916123920.48704-6-linmiaohe@huawei.com
      Fixes: d1b2cf6c
      
       ("mm: memcg/slab: uncharge during kmem_cache_free_bulk()")
      Signed-off-by: default avatarMiaohe Lin <linmiaohe@huawei.com>
      Reviewed-by: default avatarVlastimil Babka <vbabka@suse.cz>
      Cc: Andrey Konovalov <andreyknvl@gmail.com>
      Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
      Cc: Bharata B Rao <bharata@linux.ibm.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Faiyaz Mohammed <faiyazm@codeaurora.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: Roman Gushchin <guro@fb.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      3ddd6026
    • Miaohe Lin's avatar
      mm, slub: fix potential use-after-free in slab_debugfs_fops · 67823a54
      Miaohe Lin authored
      When sysfs_slab_add failed, we shouldn't call debugfs_slab_add() for s
      because s will be freed soon.  And slab_debugfs_fops will use s later
      leading to a use-after-free.
      
      Link: https://lkml.kernel.org/r/20210916123920.48704-5-linmiaohe@huawei.com
      Fixes: 64dd6849
      
       ("mm: slub: move sysfs slab alloc/free interfaces to debugfs")
      Signed-off-by: default avatarMiaohe Lin <linmiaohe@huawei.com>
      Reviewed-by: default avatarVlastimil Babka <vbabka@suse.cz>
      Cc: Andrey Konovalov <andreyknvl@gmail.com>
      Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
      Cc: Bharata B Rao <bharata@linux.ibm.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Faiyaz Mohammed <faiyazm@codeaurora.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: Roman Gushchin <guro@fb.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      67823a54
    • Miaohe Lin's avatar
      mm, slub: fix potential memoryleak in kmem_cache_open() · 9037c576
      Miaohe Lin authored
      In error path, the random_seq of slub cache might be leaked.  Fix this
      by using __kmem_cache_release() to release all the relevant resources.
      
      Link: https://lkml.kernel.org/r/20210916123920.48704-4-linmiaohe@huawei.com
      Fixes: 210e7a43
      
       ("mm: SLUB freelist randomization")
      Signed-off-by: default avatarMiaohe Lin <linmiaohe@huawei.com>
      Reviewed-by: default avatarVlastimil Babka <vbabka@suse.cz>
      Cc: Andrey Konovalov <andreyknvl@gmail.com>
      Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
      Cc: Bharata B Rao <bharata@linux.ibm.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Faiyaz Mohammed <faiyazm@codeaurora.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: Roman Gushchin <guro@fb.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      9037c576
    • Miaohe Lin's avatar
      mm, slub: fix mismatch between reconstructed freelist depth and cnt · 899447f6
      Miaohe Lin authored
      If object's reuse is delayed, it will be excluded from the reconstructed
      freelist.  But we forgot to adjust the cnt accordingly.  So there will
      be a mismatch between reconstructed freelist depth and cnt.  This will
      lead to free_debug_processing() complaining about freelist count or a
      incorrect slub inuse count.
      
      Link: https://lkml.kernel.org/r/20210916123920.48704-3-linmiaohe@huawei.com
      Fixes: c3895391
      
       ("kasan, slub: fix handling of kasan_slab_free hook")
      Signed-off-by: default avatarMiaohe Lin <linmiaohe@huawei.com>
      Reviewed-by: default avatarVlastimil Babka <vbabka@suse.cz>
      Cc: Andrey Konovalov <andreyknvl@gmail.com>
      Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
      Cc: Bharata B Rao <bharata@linux.ibm.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Faiyaz Mohammed <faiyazm@codeaurora.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: Roman Gushchin <guro@fb.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      899447f6
    • Miaohe Lin's avatar
      mm, slub: fix two bugs in slab_debug_trace_open() · 2127d225
      Miaohe Lin authored
      Patch series "Fixups for slub".
      
      This series contains various bug fixes for slub.  We fix memoryleak,
      use-afer-free, NULL pointer dereferencing and so on in slub.  More
      details can be found in the respective changelogs.
      
      This patch (of 5):
      
      It's possible that __seq_open_private() will return NULL.  So we should
      check it before using lest dereferencing NULL pointer.  And in error
      paths, we forgot to release private buffer via seq_release_private().
      Memory will leak in these paths.
      
      Link: https://lkml.kernel.org/r/20210916123920.48704-1-linmiaohe@huawei.com
      Link: https://lkml.kernel.org/r/20210916123920.48704-2-linmiaohe@huawei.com
      Fixes: 64dd6849
      
       ("mm: slub: move sysfs slab alloc/free interfaces to debugfs")
      Signed-off-by: default avatarMiaohe Lin <linmiaohe@huawei.com>
      Reviewed-by: default avatarVlastimil Babka <vbabka@suse.cz>
      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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Faiyaz Mohammed <faiyazm@codeaurora.org>
      Cc: Andrey Konovalov <andreyknvl@gmail.com>
      Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Bharata B Rao <bharata@linux.ibm.com>
      Cc: Roman Gushchin <guro@fb.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      2127d225
    • Eric Dumazet's avatar
      mm/mempolicy: do not allow illegal MPOL_F_NUMA_BALANCING | MPOL_LOCAL in mbind() · 6d2aec9e
      Eric Dumazet authored
      syzbot reported access to unitialized memory in mbind() [1]
      
      Issue came with commit bda420b9 ("numa balancing: migrate on fault
      among multiple bound nodes")
      
      This commit added a new bit in MPOL_MODE_FLAGS, but only checked valid
      combination (MPOL_F_NUMA_BALANCING can only be used with MPOL_BIND) in
      do_set_mempolicy()
      
      This patch moves the check in sanitize_mpol_flags() so that it is also
      used by mbind()
      
        [1]
        BUG: KMSAN: uninit-value in __mpol_equal+0x567/0x590 mm/mempolicy.c:2260
         __mpol_equal+0x567/0x590 mm/mempolicy.c:2260
         mpol_equal include/linux/mempolicy.h:105 [inline]
         vma_merge+0x4a1/0x1e60 mm/mmap.c:1190
         mbind_range+0xcc8/0x1e80 mm/mempolicy.c:811
         do_mbind+0xf42/0x15f0 mm/mempolicy.c:1333
         kernel_mbind mm/mempolicy.c:1483 [inline]
         __do_sys_mbind mm/mempolicy.c:1490 [inline]
         __se_sys_mbind+0x437/0xb80 mm/mempolicy.c:1486
         __x64_sys_mbind+0x19d/0x200 mm/mempolicy.c:1486
         do_syscall_x64 arch/x86/entry/common.c:51 [inline]
         do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82
         entry_SYSCALL_64_after_hwframe+0x44/0xae
      
        Uninit was created at:
         slab_alloc_node mm/slub.c:3221 [inline]
         slab_alloc mm/slub.c:3230 [inline]
         kmem_cache_alloc+0x751/0xff0 mm/slub.c:3235
         mpol_new mm/mempolicy.c:293 [inline]
         do_mbind+0x912/0x15f0 mm/mempolicy.c:1289
         kernel_mbind mm/mempolicy.c:1483 [inline]
         __do_sys_mbind mm/mempolicy.c:1490 [inline]
         __se_sys_mbind+0x437/0xb80 mm/mempolicy.c:1486
         __x64_sys_mbind+0x19d/0x200 mm/mempolicy.c:1486
         do_syscall_x64 arch/x86/entry/common.c:51 [inline]
         do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82
         entry_SYSCALL_64_after_hwframe+0x44/0xae
        =====================================================
        Kernel panic - not syncing: panic_on_kmsan set ...
        CPU: 0 PID: 15049 Comm: syz-executor.0 Tainted: G    B             5.15.0-rc2-syzkaller #0
        Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
        Call Trace:
         __dump_stack lib/dump_stack.c:88 [inline]
         dump_stack_lvl+0x1ff/0x28e lib/dump_stack.c:106
         dump_stack+0x25/0x28 lib/dump_stack.c:113
         panic+0x44f/0xdeb kernel/panic.c:232
         kmsan_report+0x2ee/0x300 mm/kmsan/report.c:186
         __msan_warning+0xd7/0x150 mm/kmsan/instrumentation.c:208
         __mpol_equal+0x567/0x590 mm/mempolicy.c:2260
         mpol_equal include/linux/mempolicy.h:105 [inline]
         vma_merge+0x4a1/0x1e60 mm/mmap.c:1190
         mbind_range+0xcc8/0x1e80 mm/mempolicy.c:811
         do_mbind+0xf42/0x15f0 mm/mempolicy.c:1333
         kernel_mbind mm/mempolicy.c:1483 [inline]
         __do_sys_mbind mm/mempolicy.c:1490 [inline]
         __se_sys_mbind+0x437/0xb80 mm/mempolicy.c:1486
         __x64_sys_mbind+0x19d/0x200 mm/mempolicy.c:1486
         do_syscall_x64 arch/x86/entry/common.c:51 [inline]
         do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82
         entry_SYSCALL_64_after_hwframe+0x44/0xae
      
      Link: https://lkml.kernel.org/r/20211001215630.810592-1-eric.dumazet@gmail.com
      Fixes: bda420b9
      
       ("numa balancing: migrate on fault among multiple bound nodes")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Acked-by: default avatarMel Gorman <mgorman@suse.de>
      Cc: "Huang, Ying" <ying.huang@intel.com>
      Cc: Matthew Wilcox <willy@infradead.org>
      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>
      6d2aec9e
    • Peng Fan's avatar
      memblock: check memory total_size · 5173ed72
      Peng Fan authored
      mem=[X][G|M] is broken on ARM64 platform, there are cases that even
      type.cnt is 1, but total_size is not 0 because regions are merged into
      1.  So only check 'cnt' is not enough, total_size should be used,
      othersize bootargs 'mem=[X][G|B]' not work anymore.
      
      Link: https://lkml.kernel.org/r/20210930024437.32598-1-peng.fan@oss.nxp.com
      Fixes: e888fa7b
      
       ("memblock: Check memory add/cap ordering")
      Signed-off-by: default avatarPeng Fan <peng.fan@nxp.com>
      Reviewed-by: default avatarMike Rapoport <rppt@linux.ibm.com>
      Cc: Geert Uytterhoeven <geert+renesas@glider.be>
      Cc: David Hildenbrand <david@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      5173ed72
    • Valentin Vidic's avatar
      ocfs2: mount fails with buffer overflow in strlen · b15fa922
      Valentin Vidic authored
      Starting with kernel 5.11 built with CONFIG_FORTIFY_SOURCE mouting an
      ocfs2 filesystem with either o2cb or pcmk cluster stack fails with the
      trace below.  Problem seems to be that strings for cluster stack and
      cluster name are not guaranteed to be null terminated in the disk
      representation, while strlcpy assumes that the source string is always
      null terminated.  This causes a read outside of the source string
      triggering the buffer overflow detection.
      
        detected buffer overflow in strlen
        ------------[ cut here ]------------
        kernel BUG at lib/string.c:1149!
        invalid opcode: 0000 [#1] SMP PTI
        CPU: 1 PID: 910 Comm: mount.ocfs2 Not tainted 5.14.0-1-amd64 #1
          Debian 5.14.6-2
        RIP: 0010:fortify_panic+0xf/0x11
        ...
        Call Trace:
         ocfs2_initialize_super.isra.0.cold+0xc/0x18 [ocfs2]
         ocfs2_fill_super+0x359/0x19b0 [ocfs2]
         mount_bdev+0x185/0x1b0
         legacy_get_tree+0x27/0x40
         vfs_get_tree+0x25/0xb0
         path_mount+0x454/0xa20
         __x64_sys_mount+0x103/0x140
         do_syscall_64+0x3b/0xc0
         entry_SYSCALL_64_after_hwframe+0x44/0xae
      
      Link: https://lkml.kernel.org/r/20210929180654.32460-1-vvidic@valentin-vidic.from.hr
      
      
      Signed-off-by: default avatarValentin Vidic <vvidic@valentin-vidic.from.hr>
      Reviewed-by: default avatarJoseph Qi <joseph.qi@linux.alibaba.com>
      Cc: Mark Fasheh <mark@fasheh.com>
      Cc: Joel Becker <jlbec@evilplan.org>
      Cc: Junxiao Bi <junxiao.bi@oracle.com>
      Cc: Changwei Ge <gechangwei@live.cn>
      Cc: Gang He <ghe@suse.com>
      Cc: Jun Piao <piaojun@huawei.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b15fa922
    • Jan Kara's avatar
      ocfs2: fix data corruption after conversion from inline format · 5314454e
      Jan Kara authored
      Commit 6dbf7bb5 ("fs: Don't invalidate page buffers in
      block_write_full_page()") uncovered a latent bug in ocfs2 conversion
      from inline inode format to a normal inode format.
      
      The code in ocfs2_convert_inline_data_to_extents() attempts to zero out
      the whole cluster allocated for file data by grabbing, zeroing, and
      dirtying all pages covering this cluster.  However these pages are
      beyond i_size, thus writeback code generally ignores these dirty pages
      and no blocks were ever actually zeroed on the disk.
      
      This oversight was fixed by commit 693c241a ("ocfs2: No need to zero
      pages past i_size.") for standard ocfs2 write path, inline conversion
      path was apparently forgotten; the commit log also has a reasoning why
      the zeroing actually is not needed.
      
      After commit 6dbf7bb5, things became worse as writeback code stopped
      invalidating buffers on pages beyond i_size and thus these pages end up
      with clean PageDirty bit but with buffers attached to these pages being
      still dirty.  So when a file is converted from inline format, then
      writeback triggers, and then the file is grown so that these pages
      become valid, the invalid dirtiness state is preserved,
      mark_buffer_dirty() does nothing on these pages (buffers are already
      dirty) but page is never written back because it is clean.  So data
      written to these pages is lost once pages are reclaimed.
      
      Simple reproducer for the problem is:
      
        xfs_io -f -c "pwrite 0 2000" -c "pwrite 2000 2000" -c "fsync" \
          -c "pwrite 4000 2000" ocfs2_file
      
      After unmounting and mounting the fs again, you can observe that end of
      'ocfs2_file' has lost its contents.
      
      Fix the problem by not doing the pointless zeroing during conversion
      from inline format similarly as in the standard write path.
      
      [akpm@linux-foundation.org: fix whitespace, per Joseph]
      
      Link: https://lkml.kernel.org/r/20210930095405.21433-1-jack@suse.cz
      Fixes: 6dbf7bb5
      
       ("fs: Don't invalidate page buffers in block_write_full_page()")
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Reviewed-by: default avatarJoseph Qi <joseph.qi@linux.alibaba.com>
      Tested-by: default avatarJoseph Qi <joseph.qi@linux.alibaba.com>
      Acked-by: default avatarGang He <ghe@suse.com>
      Cc: Mark Fasheh <mark@fasheh.com>
      Cc: Joel Becker <jlbec@evilplan.org>
      Cc: Junxiao Bi <junxiao.bi@oracle.com>
      Cc: Changwei Ge <gechangwei@live.cn>
      Cc: Jun Piao <piaojun@huawei.com>
      Cc: "Markov, Andrey" <Markov.Andrey@Dell.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      5314454e
    • Huang Ying's avatar
      mm/migrate: fix CPUHP state to update node demotion order · a6a0251c
      Huang Ying authored
      The node demotion order needs to be updated during CPU hotplug.  Because
      whether a NUMA node has CPU may influence the demotion order.  The
      update function should be called during CPU online/offline after the
      node_states[N_CPU] has been updated.  That is done in
      CPUHP_AP_ONLINE_DYN during CPU online and in CPUHP_MM_VMSTAT_DEAD during
      CPU offline.  But in commit 884a6e5d ("mm/migrate: update node
      demotion order on hotplug events"), the function to update node demotion
      order is called in CPUHP_AP_ONLINE_DYN during CPU online/offline.  This
      doesn't satisfy the order requirement.
      
      For example, there are 4 CPUs (P0, P1, P2, P3) in 2 sockets (P0, P1 in S0
      and P2, P3 in S1), the demotion order is
      
       - S0 -> NUMA_NO_NODE
       - S1 -> NUMA_NO_NODE
      
      After P2 and P3 is offlined, because S1 has no CPU now, the demotion
      order should have been changed to
      
       - S0 -> S1
       - S1 -> NO_NODE
      
      but it isn't changed, because the order updating callback for CPU
      hotplug doesn't see the new nodemask.  After that, if P1 is offlined,
      the demotion order is changed to the expected order as above.
      
      So in this patch, we added CPUHP_AP_MM_DEMOTION_ONLINE and
      CPUHP_MM_DEMOTION_DEAD to be called after CPUHP_AP_ONLINE_DYN and
      CPUHP_MM_VMSTAT_DEAD during CPU online and offline, and register the
      update function on them.
      
      Link: https://lkml.kernel.org/r/20210929060351.7293-1-ying.huang@intel.com
      Fixes: 884a6e5d
      
       ("mm/migrate: update node demotion order on hotplug events")
      Signed-off-by: default avatar"Huang, Ying" <ying.huang@intel.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Yang Shi <shy828301@gmail.com>
      Cc: Zi Yan <ziy@nvidia.com>
      Cc: Michal Hocko <mhocko@suse.com>
      Cc: Wei Xu <weixugc@google.com>
      Cc: Oscar Salvador <osalvador@suse.de>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: David Hildenbrand <david@redhat.com>
      Cc: Greg Thelen <gthelen@google.com>
      Cc: Keith Busch <kbusch@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a6a0251c
    • Dave Hansen's avatar
      mm/migrate: add CPU hotplug to demotion #ifdef · 76af6a05
      Dave Hansen authored
      Once upon a time, the node demotion updates were driven solely by memory
      hotplug events.  But now, there are handlers for both CPU and memory
      hotplug.
      
      However, the #ifdef around the code checks only memory hotplug.  A
      system that has HOTPLUG_CPU=y but MEMORY_HOTPLUG=n would miss CPU
      hotplug events.
      
      Update the #ifdef around the common code.  Add memory and CPU-specific
      #ifdefs for their handlers.  These memory/CPU #ifdefs avoid unused
      function warnings when their Kconfig option is off.
      
      [arnd@arndb.de: rework hotplug_memory_notifier() stub]
        Link: https://lkml.kernel.org/r/20211013144029.2154629-1-arnd@kernel.org
      
      Link: https://lkml.kernel.org/r/20210924161255.E5FE8F7E@davehans-spike.ostc.intel.com
      Fixes: 884a6e5d
      
       ("mm/migrate: update node demotion order on hotplug events")
      Signed-off-by: default avatarDave Hansen <dave.hansen@linux.intel.com>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Cc: "Huang, Ying" <ying.huang@intel.com>
      Cc: Michal Hocko <mhocko@suse.com>
      Cc: Wei Xu <weixugc@google.com>
      Cc: Oscar Salvador <osalvador@suse.de>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: David Hildenbrand <david@redhat.com>
      Cc: Greg Thelen <gthelen@google.com>
      Cc: Yang Shi <yang.shi@linux.alibaba.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      76af6a05
    • Dave Hansen's avatar
      mm/migrate: optimize hotplug-time demotion order updates · 295be91f
      Dave Hansen authored
      Patch series "mm/migrate: 5.15 fixes for automatic demotion", v2.
      
      This contains two fixes for the "automatic demotion" code which was
      merged into 5.15:
      
       * Fix memory hotplug performance regression by watching
         suppressing any real action on irrelevant hotplug events.
      
       * Ensure CPU hotplug handler is registered when memory hotplug
         is disabled.
      
      This patch (of 2):
      
      == tl;dr ==
      
      Automatic demotion opted for a simple, lazy approach to handling hotplug
      events.  This noticeably slows down memory hotplug[1].  Optimize away
      updates to the demotion order when memory hotplug events should have no
      effect.
      
      This has no effect on CPU hotplug.  There is no known problem on the CPU
      side and any work there will be in a separate series.
      
      == Background ==
      
      Automatic demotion is a memory migration strategy to ensure that new
      allocations have room in faster memory tiers on tiered memory systems.
      The kernel maintains an array (node_demotion[]) to drive these
      migrations.
      
      The node_demotion[] path is calculated by starting at nodes with CPUs
      and then "walking" to nodes with memory.  Only hotplug events which
      online or offline a node with memory (N_ONLINE) or CPUs (N_CPU) will
      actually affect the migration order.
      
      == Problem ==
      
      However, the current code is lazy.  It completely regenerates the
      migration order on *any* CPU or memory hotplug event.  The logic was
      that these events are extremely rare and that the overhead from
      indiscriminate order regeneration is minimal.
      
      Part of the update logic involves a synchronize_rcu(), which is a pretty
      big hammer.  Its overhead was large enough to be detected by some 0day
      tests that watch memory hotplug performance[1].
      
      == Solution ==
      
      Add a new helper (node_demotion_topo_changed()) which can differentiate
      between superfluous and impactful hotplug events.  Skip the expensive
      update operation for superfluous events.
      
      == Aside: Locking ==
      
      It took me a few moments to declare the locking to be safe enough for
      node_demotion_topo_changed() to work.  It all hinges on the memory
      hotplug lock:
      
      During memory hotplug events, 'mem_hotplug_lock' is held for write.
      This ensures that two memory hotplug events can not be called
      simultaneously.
      
      CPU hotplug has a similar lock (cpuhp_state_mutex) which also provides
      mutual exclusion between CPU hotplug events.  In addition, the demotion
      code acquire and hold the mem_hotplug_lock for read during its CPU
      hotplug handlers.  This provides mutual exclusion between the demotion
      memory hotplug callbacks and the CPU hotplug callbacks.
      
      This effectively allows treating the migration target generation code to
      act as if it is single-threaded.
      
      1. https://lore.kernel.org/all/20210905135932.GE15026@xsang-OptiPlex-9020/
      
      Link: https://lkml.kernel.org/r/20210924161251.093CCD06@davehans-spike.ostc.intel.com
      Link: https://lkml.kernel.org/r/20210924161253.D7673E31@davehans-spike.ostc.intel.com
      Fixes: 884a6e5d
      
       ("mm/migrate: update node demotion order on hotplug events")
      Signed-off-by: default avatarDave Hansen <dave.hansen@linux.intel.com>
      Reported-by: default avatarkernel test robot <oliver.sang@intel.com>
      Reviewed-by: default avatarDavid Hildenbrand <david@redhat.com>
      Cc: "Huang, Ying" <ying.huang@intel.com>
      Cc: Michal Hocko <mhocko@suse.com>
      Cc: Wei Xu <weixugc@google.com>
      Cc: Oscar Salvador <osalvador@suse.de>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Greg Thelen <gthelen@google.com>
      Cc: Yang Shi <yang.shi@linux.alibaba.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      295be91f
    • Nadav Amit's avatar
      userfaultfd: fix a race between writeprotect and exit_mmap() · cb185d5f
      Nadav Amit authored
      A race is possible when a process exits, its VMAs are removed by
      exit_mmap() and at the same time userfaultfd_writeprotect() is called.
      
      The race was detected by KASAN on a development kernel, but it appears
      to be possible on vanilla kernels as well.
      
      Use mmget_not_zero() to prevent the race as done in other userfaultfd
      operations.
      
      Link: https://lkml.kernel.org/r/20210921200247.25749-1-namit@vmware.com
      Fixes: 63b2d417
      
       ("userfaultfd: wp: add the writeprotect API to userfaultfd ioctl")
      Signed-off-by: default avatarNadav Amit <namit@vmware.com>
      Tested-by: default avatarLi Wang <liwang@redhat.com>
      Reviewed-by: default avatarPeter Xu <peterx@redhat.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      cb185d5f
    • Peter Xu's avatar
      mm/userfaultfd: selftests: fix memory corruption with thp enabled · 8913970c
      Peter Xu authored
      In RHEL's gating selftests we've encountered memory corruption in the
      uffd event test even with upstream kernel:
      
              # ./userfaultfd anon 128 4
              nr_pages: 32768, nr_pages_per_cpu: 32768
              bounces: 3, mode: rnd racing read, userfaults: 6240 missing (6240) 14729 wp (14729)
              bounces: 2, mode: racing read, userfaults: 1444 missing (1444) 28877 wp (28877)
              bounces: 1, mode: rnd read, userfaults: 6055 missing (6055) 14699 wp (14699)
              bounces: 0, mode: read, userfaults: 82 missing (82) 25196 wp (25196)
              testing uffd-wp with pagemap (pgsize=4096): done
              testing uffd-wp with pagemap (pgsize=2097152): done
              testing events (fork, remap, remove): ERROR: nr 32427 memory corruption 0 1 (errno=0, line=963)
              ERROR: faulting process failed (errno=0, line=1117)
      
      It can be easily reproduced when global thp enabled, which is the
      default for RHEL.
      
      It's also known as a side effect of commit 0db282ba ("selftest: use
      mmap instead of posix_memalign to allocate memory", 2021-07-23), which
      is imho right itself on using mmap() to make sure the addresses will be
      untagged even on arm.
      
      The problem is, for each test we allocate buffers using two
      allocate_area() calls.  We assumed these two buffers won't affect each
      other, however they could, because mmap() could have found that the two
      buffers are near each other and having the same VMA flags, so they got
      merged into one VMA.
      
      It won't be a big problem if thp is not enabled, but when thp is
      agressively enabled it means when initializing the src buffer it could
      accidentally setup part of the dest buffer too when there's a shared THP
      that overlaps the two regions.  Then some of the dest buffer won't be
      able to be trapped by userfaultfd missing mode, then it'll cause memory
      corruption as described.
      
      To fix it, do release_pages() after initializing the src buffer.
      
      Since the previous two release_pages() calls are after
      uffd_test_ctx_clear() which will unmap all the buffers anyway (which is
      stronger than release pages; as unmap() also tear town pgtables), drop
      them as they shouldn't really be anything useful.
      
      We can mark the Fixes tag upon 0db282ba as it's reported to only
      happen there, however the real "Fixes" IMHO should be 8ba6e864, as
      before that commit we'll always do explicit release_pages() before
      registration of uffd, and 8ba6e864 changed that logic by adding
      extra unmap/map and we didn't release the pages at the right place.
      Meanwhile I don't have a solid glue anyway on whether posix_memalign()
      could always avoid triggering this bug, hence it's safer to attach this
      fix to commit 8ba6e864.
      
      Link: https://lkml.kernel.org/r/20210923232512.210092-1-peterx@redhat.com
      Fixes: 8ba6e864 ("userfaultfd/selftests: reinitialize test context in each test")
      Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1994931
      
      
      Signed-off-by: default avatarPeter Xu <peterx@redhat.com>
      Reported-by: default avatarLi Wang <liwan@redhat.com>
      Tested-by: default avatarLi Wang <liwang@redhat.com>
      Reviewed-by: default avatarAxel Rasmussen <axelrasmussen@google.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: Nadav Amit <nadav.amit@gmail.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      8913970c
  2. 18 Oct, 2021 17 commits
  3. 17 Oct, 2021 2 commits