[PATCH 2/6] mm: Lock kernel page tables before entering lazy MMU mode
Uladzislau Rezki
urezki at gmail.com
Thu Jun 19 19:53:38 AEST 2025
On Wed, Jun 18, 2025 at 08:32:28PM +0300, Dan Carpenter wrote:
> Hi Alexander,
>
> kernel test robot noticed the following build warnings:
>
> url: https://github.com/intel-lab-lkp/linux/commits/Alexander-Gordeev/mm-Cleanup-apply_to_pte_range-routine/20250613-013835
> base: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-everything
> patch link: https://lore.kernel.org/r/7bd3a45dbc375dc2c15cebae09cb2bb972d6039f.1749747752.git.agordeev%40linux.ibm.com
> patch subject: [PATCH 2/6] mm: Lock kernel page tables before entering lazy MMU mode
> config: x86_64-randconfig-161-20250613 (https://download.01.org/0day-ci/archive/20250613/202506132017.T1l1l6ME-lkp@intel.com/config)
> compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
>
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <lkp at intel.com>
> | Reported-by: Dan Carpenter <dan.carpenter at linaro.org>
> | Closes: https://lore.kernel.org/r/202506132017.T1l1l6ME-lkp@intel.com/
>
> smatch warnings:
> mm/vmalloc.c:552 vmap_pages_pte_range() warn: inconsistent returns 'global &init_mm.page_table_lock'.
>
> vim +552 mm/vmalloc.c
>
> 0a264884046f1ab Nicholas Piggin 2021-04-29 517 static int vmap_pages_pte_range(pmd_t *pmd, unsigned long addr,
> 2ba3e6947aed9bb Joerg Roedel 2020-06-01 518 unsigned long end, pgprot_t prot, struct page **pages, int *nr,
> 2ba3e6947aed9bb Joerg Roedel 2020-06-01 519 pgtbl_mod_mask *mask)
> ^1da177e4c3f415 Linus Torvalds 2005-04-16 520 {
> ^1da177e4c3f415 Linus Torvalds 2005-04-16 521 pte_t *pte;
> ^1da177e4c3f415 Linus Torvalds 2005-04-16 522
> db64fe02258f150 Nicholas Piggin 2008-10-18 523 /*
> db64fe02258f150 Nicholas Piggin 2008-10-18 524 * nr is a running index into the array which helps higher level
> db64fe02258f150 Nicholas Piggin 2008-10-18 525 * callers keep track of where we're up to.
> db64fe02258f150 Nicholas Piggin 2008-10-18 526 */
> db64fe02258f150 Nicholas Piggin 2008-10-18 527
> 2ba3e6947aed9bb Joerg Roedel 2020-06-01 528 pte = pte_alloc_kernel_track(pmd, addr, mask);
> ^1da177e4c3f415 Linus Torvalds 2005-04-16 529 if (!pte)
> ^1da177e4c3f415 Linus Torvalds 2005-04-16 530 return -ENOMEM;
> 44562c71e2cfc9e Ryan Roberts 2025-04-22 531
> dac0cc793368851 Alexander Gordeev 2025-06-12 532 spin_lock(&init_mm.page_table_lock);
> 44562c71e2cfc9e Ryan Roberts 2025-04-22 533 arch_enter_lazy_mmu_mode();
> 44562c71e2cfc9e Ryan Roberts 2025-04-22 534
> ^1da177e4c3f415 Linus Torvalds 2005-04-16 535 do {
> db64fe02258f150 Nicholas Piggin 2008-10-18 536 struct page *page = pages[*nr];
> db64fe02258f150 Nicholas Piggin 2008-10-18 537
> c33c794828f2121 Ryan Roberts 2023-06-12 538 if (WARN_ON(!pte_none(ptep_get(pte))))
> db64fe02258f150 Nicholas Piggin 2008-10-18 539 return -EBUSY;
> db64fe02258f150 Nicholas Piggin 2008-10-18 540 if (WARN_ON(!page))
> ^1da177e4c3f415 Linus Torvalds 2005-04-16 541 return -ENOMEM;
> 4fcdcc12915c707 Yury Norov 2022-04-28 542 if (WARN_ON(!pfn_valid(page_to_pfn(page))))
> 4fcdcc12915c707 Yury Norov 2022-04-28 543 return -EINVAL;
>
> These error paths don't unlock &init_mm.page_table_lock?
>
> 4fcdcc12915c707 Yury Norov 2022-04-28 544
> ^1da177e4c3f415 Linus Torvalds 2005-04-16 545 set_pte_at(&init_mm, addr, pte, mk_pte(page, prot));
> db64fe02258f150 Nicholas Piggin 2008-10-18 546 (*nr)++;
> ^1da177e4c3f415 Linus Torvalds 2005-04-16 547 } while (pte++, addr += PAGE_SIZE, addr != end);
> 44562c71e2cfc9e Ryan Roberts 2025-04-22 548
> 44562c71e2cfc9e Ryan Roberts 2025-04-22 549 arch_leave_lazy_mmu_mode();
> dac0cc793368851 Alexander Gordeev 2025-06-12 550 spin_unlock(&init_mm.page_table_lock);
> 2ba3e6947aed9bb Joerg Roedel 2020-06-01 551 *mask |= PGTBL_PTE_MODIFIED;
> ^1da177e4c3f415 Linus Torvalds 2005-04-16 @552 return 0;
> ^1da177e4c3f415 Linus Torvalds 2005-04-16 553 }
>
> --
> 0-DAY CI Kernel Test Service
> https://github.com/intel/lkp-tests/wiki
>
>
This patch introduce a huge performance degrade when testing this by
the test_vmalloc.sh performance tool. We return back to a single, not
serialized global spilock where we spend 90% of cycles:
<snip>
+ 91.01% 1.67% [kernel] [k] _raw_spin_lock
- 89.29% 89.25% [kernel] [k] native_queued_spin_lock_slowpath
69.82% ret_from_fork_asm
- ret_from_fork
- 69.81% kthread
- 69.66% test_func
- 26.31% full_fit_alloc_test
- 19.11% __vmalloc_node_noprof
- __vmalloc_node_range_noprof
- 13.73% vmap_small_pages_range_noflush
_raw_spin_lock
native_queued_spin_lock_slowpath
- 5.38% __get_vm_area_node
alloc_vmap_area
_raw_spin_lock
native_queued_spin_lock_slowpath
- 13.32% vfree.part.0
- 13.31% remove_vm_area
- 13.27% __vunmap_range_noflush
_raw_spin_lock
native_queued_spin_lock_slowpath
- 25.57% fix_size_alloc_test
- 22.59% __vmalloc_node_noprof
- __vmalloc_node_range_noprof
- 17.34% vmap_small_pages_range_noflush
_raw_spin_lock
native_queued_spin_lock_slowpath
- 5.25% __get_vm_area_node
alloc_vmap_area
_raw_spin_lock
native_queued_spin_lock_slowpath
- 11.59% vfree.part.0
- remove_vm_area
- 11.55% __vunmap_range_noflush
_raw_spin_lock
native_queued_spin_lock_slowpath
- 17.78% long_busy_list_alloc_test
- 13.90% __vmalloc_node_noprof
- __vmalloc_node_range_noprof
- 9.95% vmap_small_pages_range_noflush
_raw_spin_lock
<snip>
No, we can not take this patch.
--
Uladzislau Rezki
More information about the Linuxppc-dev
mailing list