Re: [PATCH v4 01/12] mm/khugepaged: deposit a newly allocated page table on collapse

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] mm: missing error code assignment on alloc_deposit_pte() failure
--

commit 554c24d600473369b27779719cc9b7a86d682229
Author: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Subject: mm/khugepaged: deposit a newly allocated page table on collapse

This commit updates collapse_huge_page() to allocate and deposit a fresh,
zeroed PTE page table on PMD collapse instead of reusing the currently
mapped one. This resolves issues with RCU-safe page table traversal by
ensuring standard page table walkers can traverse safely during the grace
period.

> diff --git a/mm/khugepaged.c b/mm/khugepaged.c
> --- a/mm/khugepaged.c
> +++ b/mm/khugepaged.c
[ ... ]
> @@ -1310,6 +1327,12 @@ static enum scan_result collapse_huge_page(struct mm_struct *mm, unsigned long s
>  		goto out_nolock;
>  	}
>  
> +	if (is_pmd_order(order)) {
> +		pgtable = alloc_deposit_pte(mm);
> +		if (!pgtable)
> +			goto out_nolock;

[Severity: Medium]
Should the result variable be updated to an error code before jumping to
out_nolock here?

If alloc_deposit_pte() fails, result retains its SCAN_SUCCEED value from
the successful alloc_charge_folio() call above. Returning success when the
collapse actually failed could cause MADV_COLLAPSE to incorrectly return
success to userspace, corrupt khugepaged statistics, and cause mTHP
fallback logic to incorrectly assume the collapse succeeded.

> +	}
> +
>  	mmap_read_lock(mm);
>  	result = hugepage_vma_revalidate(mm, pmd_addr, /*expect_anon=*/ true,
[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260922-rcu-pagetable-freeing-v4-0-fe1ad1f1e303@kernel.org?part=1