Re: [PATCH v2 11/13] mm/mlock: convert mlock code to use vma_flags_t

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Page table walk callbacks trigger an infinite loop when pte_offset_map_lock() fails.
--

--- Patch [11]: [PATCH v2 11/13] mm/mlock: convert mlock code to use vma_flags_t ---
commit 4497d6e0c6929dd585b156beb8ad3252bc077a68
Author: Lorenzo Stoakes <ljs@kernel.org>

mm/mlock: convert mlock code to use vma_flags_t

Replace use of the legacy vm_flags_t flags with vma_flags_t values
throughout the mlock logic. No functional change intended.

> diff --git a/mm/mlock.c b/mm/mlock.c
> index 34ffa954006fb..efa6716e4dfbd 100644
> --- a/mm/mlock.c
> +++ b/mm/mlock.c

[ ... ]

> @@ -368,7 +368,7 @@ static int mlock_pte_range(pmd_t *pmd, unsigned long addr,
>  		folio = pmd_folio(*pmd);
>  		if (folio_is_zone_device(folio))
>  			goto out;
> -		if (vma->vm_flags & VM_LOCKED)
> +		if (vma_test(vma, VMA_LOCKED_BIT))
>  			mlock_folio(folio);
>  		else
>  			munlock_folio(folio);

[Severity: High]
This isn't a bug introduced by this patch, but while reviewing this function, I
noticed a potential infinite loop in mlock_pte_range(). 

When pte_offset_map_lock() returns NULL (for example, when encountering a
non-present PMD migration entry during concurrent THP migration), the callback
sets ACTION_AGAIN and returns 0:

	start_pte = pte_offset_map_lock(vma->vm_mm, pmd, addr, &ptl);
	if (!start_pte) {
		walk->action = ACTION_AGAIN;
		return 0;
	}

Does this cause walk_pmd_range() to continuously retry without yielding the
CPU? 

Because the function returns 0, it entirely bypasses the cond_resched()
call at the end of mlock_pte_range(). Meanwhile, ACTION_AGAIN instructs
walk_pmd_range() to jump to its retry label and re-process the exact same
PMD. 

Could an unprivileged user space process trigger a soft or hard CPU lockup
by calling mlock() on a memory range during a concurrent migration?

I also noticed this exact same pattern appears in other page walk callbacks
that return 0 with ACTION_AGAIN when pte_offset_map_lock() fails, such as
queue_folios_pmd(), mincore_pte_range(), smaps_pte_range(),
pagemap_pmd_range(), gather_pte_stats(), clear_refs_pte_range(), and
pagemap2_pte_range().

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260711-b4-vma-flags-mm-v2-0-0fa2357d5431@kernel.org?part=11