Re: [PATCH 04/22] mm: use mm_is_kernel() in generic page table code

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] apply_to_pte_range() routes all kernel MMs to pte_alloc_kernel_track(), which explicitly hardcodes &init_mm, leading to incorrect locking and mm attribution.
--

--- Patch [4]: [PATCH 04/22] mm: use mm_is_kernel() in generic page table code ---
commit 94fec0def7956a4362140e84c87769a3c5a046b2
Author: Kevin Brodsky <kevin.brodsky@arm.com>

mm: use mm_is_kernel() in generic page table code

Generic page-table allocation, constructor and walker code uses
init_mm comparisons to select kernel page table handling. Use
mm_is_kernel() instead so kernel-owned mm's can share that handling
once they are marked with MMF_KERNEL.

> diff --git a/mm/memory.c b/mm/memory.c
> index d5e87624f6920..c0244c0b07567 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
[ ... ]
> @@ -3394,13 +3394,13 @@ static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd,
>  	spinlock_t *ptl;
>  
>  	if (create) {
> -		mapped_pte = pte = (mm == &init_mm) ?
> +		mapped_pte = pte = mm_is_kernel(mm) ?
>  			pte_alloc_kernel_track(pmd, addr, mask) :

[Severity: Medium]
If a non-init_mm kernel MM (like efi_mm) has MMF_KERNEL set in the future,
will this route it to pte_alloc_kernel_track() which hardcodes init_mm?

Looking at __pte_alloc_kernel() in mm/memory.c, which 
pte_alloc_kernel_track() calls:

int __pte_alloc_kernel(pmd_t *pmd)
{
        pte_t *new = pte_alloc_one_kernel(&init_mm);
        if (!new)
                return -ENOMEM;

        spin_lock(&init_mm.page_table_lock);
...

Since __pte_alloc_kernel() drops the mm context and explicitly locks
init_mm.page_table_lock instead of the target MM's lock, would this
lead to data races during concurrent page table modifications for other
kernel MMs?

>  			pte_alloc_map_lock(mm, pmd, addr, &ptl);
>  		if (!pte)
>  			return -ENOMEM;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260714-remove_pgtable_cdtor-v1-0-44be8a7685d7@arm.com?part=4