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 <[email protected]>

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/[email protected]?part=11

Reply via email to