linux/mm/debug_vm_pgtable.c, branch v5.11

mm/debug_vm_pgtable: avoid doing memory allocation with pgtable_t mapped.

2020-10-16T18:11:14Z

With highmem, pte_alloc_map() keep the level4 page table mapped using kmap_atomic(). Avoid doing new memory allocation with page table mapped like above. [ 9.409233] BUG: sleeping function called from invalid context at mm/page_alloc.c:4822 [ 9.410557] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper [ 9.411932] no locks held by swapper/1. [ 9.412595] CPU: 0 PID: 1 Comm: swapper Not tainted 5.9.0-rc3-00323-gc50eb1ed654b5 #2 [ 9.413824] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 [ 9.415207] Call Trace: [ 9.415651] ? ___might_sleep.cold+0xa7/0xcc [ 9.416367] ? __alloc_pages_nodemask+0x14c/0x5b0 [ 9.417055] ? swap_migration_tests+0x50/0x293 [ 9.417704] ? debug_vm_pgtable+0x4bc/0x708 [ 9.418287] ? swap_migration_tests+0x293/0x293 [ 9.418911] ? do_one_initcall+0x82/0x3cb [ 9.419465] ? parse_args+0x1bd/0x280 [ 9.419983] ? rcu_read_lock_sched_held+0x36/0x60 [ 9.420673] ? trace_initcall_level+0x1f/0xf3 [ 9.421279] ? trace_initcall_level+0xbd/0xf3 [ 9.421881] ? do_basic_setup+0x9d/0xdd [ 9.422410] ? do_basic_setup+0xc3/0xdd [ 9.422938] ? kernel_init_freeable+0x72/0xa3 [ 9.423539] ? rest_init+0x134/0x134 [ 9.424055] ? kernel_init+0x5/0x12c [ 9.424574] ? ret_from_fork+0x19/0x30 Reported-by: kernel test robot Signed-off-by: Aneesh Kumar K.V Signed-off-by: Andrew Morton Link: https://lkml.kernel.org/r/20200913110327.645310-1-aneesh.kumar@linux.ibm.com Signed-off-by: Linus Torvalds

mm/debug_vm_pgtable: avoid none pte in pte_clear_test

2020-10-16T18:11:14Z

pte_clear_tests operate on an existing pte entry. Make sure that is not a none pte entry. [aneesh.kumar@linux.ibm.com: avoid kernel crash with riscv] Link: https://lkml.kernel.org/r/20201015033206.140550-1-aneesh.kumar@linux.ibm.com Signed-off-by: Aneesh Kumar K.V Signed-off-by: Andrew Morton Reviewed-by: Anshuman Khandual Cc: Christophe Leroy Cc: Michael Ellerman Cc: Nathan Chancellor Cc: Guenter Roeck Cc: Paul Walmsley Cc: Albert Ou Cc: Palmer Dabbelt Link: https://lkml.kernel.org/r/20200902114222.181353-14-aneesh.kumar@linux.ibm.com Signed-off-by: Linus Torvalds

mm/debug_vm_pgtable/hugetlb: disable hugetlb test on ppc64

2020-10-16T18:11:14Z

The seems to be missing quite a lot of details w.r.t allocating the correct pgtable_t page (huge_pte_alloc()), holding the right lock (huge_pte_lock()) etc. The vma used is also not a hugetlb VMA. ppc64 do have runtime checks within CONFIG_DEBUG_VM for most of these. Hence disable the test on ppc64. [anshuman.khandual@arm.com: drop hugetlb_advanced_tests()] Link: https://lore.kernel.org/lkml/289c3fdb-1394-c1af-bdc4-5542907089dc@linux.ibm.com/#t Link: https://lkml.kernel.org/r/1600914446-21890-1-git-send-email-anshuman.khandual@arm.com Signed-off-by: Aneesh Kumar K.V Signed-off-by: Anshuman Khandual Signed-off-by: Andrew Morton Cc: Christophe Leroy Cc: Michael Ellerman Link: https://lkml.kernel.org/r/20200902114222.181353-13-aneesh.kumar@linux.ibm.com Signed-off-by: Linus Torvalds

mm/debug_vm_pgtable/pmd_clear: don't use pmd/pud_clear on pte entries

2020-10-16T18:11:14Z

pmd_clear() should not be used to clear pmd level pte entries. Signed-off-by: Aneesh Kumar K.V Signed-off-by: Andrew Morton Cc: Anshuman Khandual Cc: Christophe Leroy Cc: Michael Ellerman Link: https://lkml.kernel.org/r/20200902114222.181353-12-aneesh.kumar@linux.ibm.com Signed-off-by: Linus Torvalds

mm/debug_vm_pgtable/thp: use page table depost/withdraw with THP

2020-10-16T18:11:14Z

Architectures like ppc64 use deposited page table while updating the huge pte entries. Signed-off-by: Aneesh Kumar K.V Signed-off-by: Andrew Morton Reviewed-by: Anshuman Khandual Cc: Christophe Leroy Cc: Michael Ellerman Link: https://lkml.kernel.org/r/20200902114222.181353-11-aneesh.kumar@linux.ibm.com Signed-off-by: Linus Torvalds

mm/debug_vm_pgtable/locks: take correct page table lock

2020-10-16T18:11:14Z

Make sure we call pte accessors with correct lock held. Signed-off-by: Aneesh Kumar K.V Signed-off-by: Andrew Morton Cc: Anshuman Khandual Cc: Christophe Leroy Cc: Michael Ellerman Link: https://lkml.kernel.org/r/20200902114222.181353-10-aneesh.kumar@linux.ibm.com Signed-off-by: Linus Torvalds

mm/debug_vm_pgtable/locks: move non page table modifying test together

2020-10-16T18:11:14Z

This will help in adding proper locks in a later patch Signed-off-by: Aneesh Kumar K.V Signed-off-by: Andrew Morton Cc: Anshuman Khandual Cc: Christophe Leroy Cc: Michael Ellerman Link: https://lkml.kernel.org/r/20200902114222.181353-9-aneesh.kumar@linux.ibm.com Signed-off-by: Linus Torvalds

mm/debug_vm_pgtable/set_pte/pmd/pud: don't use set_*_at to update an existing pte entry

2020-10-16T18:11:14Z

set_pte_at() should not be used to set a pte entry at locations that already holds a valid pte entry. Architectures like ppc64 don't do TLB invalidate in set_pte_at() and hence expect it to be used to set locations that are not a valid PTE. Link: https://lkml.kernel.org/r/20200902114222.181353-8-aneesh.kumar@linux.ibm.com Signed-off-by: Aneesh Kumar K.V Reviewed-by: Anshuman Khandual Cc: Christophe Leroy Cc: Michael Ellerman Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

mm/debug_vm_pgtable/savedwrite: enable savedwrite test with CONFIG_NUMA_BALANCING

2020-10-16T18:11:14Z

Saved write support was added to track the write bit of a pte after marking the pte protnone. This was done so that AUTONUMA can convert a write pte to protnone and still track the old write bit. When converting it back we set the pte write bit correctly thereby avoiding a write fault again. Hence enable the test only when CONFIG_NUMA_BALANCING is enabled and use protnone protflags. Signed-off-by: Aneesh Kumar K.V Signed-off-by: Andrew Morton Reviewed-by: Anshuman Khandual Cc: Christophe Leroy Cc: Michael Ellerman Link: https://lkml.kernel.org/r/20200902114222.181353-6-aneesh.kumar@linux.ibm.com Signed-off-by: Linus Torvalds

mm/debug_vm_pgtables/hugevmap: use the arch helper to identify huge vmap support.

2020-10-16T18:11:14Z

ppc64 supports huge vmap only with radix translation. Hence use arch helper to determine the huge vmap support. Signed-off-by: Aneesh Kumar K.V Signed-off-by: Andrew Morton Reviewed-by: Anshuman Khandual Cc: Christophe Leroy Cc: Michael Ellerman Link: https://lkml.kernel.org/r/20200902114222.181353-5-aneesh.kumar@linux.ibm.com Signed-off-by: Linus Torvalds