Re: [PATCH v5 10/36] mm/madvise: disallow madvise operations on private node folios

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

Pre-existing issues:
- [High] madvise_cold_or_pageout_pte_range() calls folio_get() before blocking on folio_lock() when attempting to split a large PMD-mapped folio, violating the required lock-before-refcount ordering for large folio splits.
--

--- Patch [10]: [PATCH v5 10/36] mm/madvise: disallow madvise operations on private node folios ---
commit 76f9465747c7c18f9f36e91d7a628706fb9905f9
Author: Gregory Price <[email protected]>

mm/madvise: disallow madvise operations on private node folios
    
Use the same filter locations as zone_device, plus additional filters
for huge pages to avoid madvise operations on private node memory.

[ ... ]
> diff --git a/mm/madvise.c b/mm/madvise.c
> index 07a21ca31bad4..29f35a23919a0 100644
> --- a/mm/madvise.c
> +++ b/mm/madvise.c
[ ... ]
> @@ -395,6 +396,9 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd,
>  
>  		folio = pmd_folio(orig_pmd);
>  
> +		if (folio_is_private_node(folio))
> +			goto huge_unlock;
> +
>  		/* Do not interfere with other mappings of this folio */
>  		if (folio_maybe_mapped_shared(folio))
>  			goto huge_unlock;

[Severity: High]
This is a pre-existing issue, but does the sequence just below this block
in madvise_cold_or_pageout_pte_range() cause split_folio() to fail under
contention?

A few lines down, the code attempts to split a PMD-mapped large folio:

    folio_get(folio);
    spin_unlock(ptl);
    folio_lock(folio);
    err = split_folio(folio);

When multiple tasks concurrently attempt to split the same folio, taking
the reference before blocking on the lock inflates the refcount. This
causes split_folio() to spuriously return -EAGAIN because the expected
refcount does not match.

Could we trylock the folio before raising the reference count here,
similar to how it is handled in madvise_free_huge_pmd() in huge_memory.c?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=10