Re: [PATCH v4 5/7] mm/khugepaged: Refactor the PTE state checks into a helper

[Nico Pache (Red Hat)]

On 8/12/26 2:56 PM, David Hildenbrand (Arm) wrote:
> On 8/12/26 21:39, Andrew Morton wrote:
>> On Wed, 12 Aug 2026 10:40:08 +0200 "David Hildenbrand (Arm)" <david@xxxxxxxxxx> wrote:
>>
>>> On 8/11/26 14:48, Nico Pache (Red Hat) wrote:
>>>> For anonymous collapse, the collapse_scan_pmd() and
>>>> __collapse_huge_page_isolate() functions share a large portion of their
>>>> logic. These functions both check the state of the PTEs and verify the
>>>> following:
>>>> 	- max_pte_* values are not exceeded
>>>> 	- uffd is not active
>>>> 	- lazyfree properties
>>>> 	- non-anonymous
>>>>
>>>> Merge these checks into a helper collapse_check_pte() to reduce code
>>>> duplication. We also add a helper struct for this function called
>>>> pte_check_context which allows us to pass the required parameters in a
>>>> clean and elegant manner.
>>>>
>>>> A helper function is also introduced pte_check_fail() to provide a clean
>>>> interface to set the pte_check_context failure results and return
>>>> PTE_CHECK_FAIL state. This helps reduce code duplications across the new
>>>> collapse_check_pte function.
>>>>
>>>> Two slight modifications are done to the original functionality. We now
>>>> warn (instead of crash) if the anon test fails, and we leverage the
>>>> vm_normal_folio function instead of page->folio, this should be
>>>> functionally equivalent.
>>>>
>>>> No other functional changes intended.
>>>>
>>>> This patch is heavily based off work done by Lance Yang, but modified to
>>>> deal with conflicts and feedback received during the review cycle [1].
>>>>
>>>
>>> TL;DR, I think this patch here needs some more work, and we should not fast
>>> track it at this point.
>>
>> This has been floating around since July 6, so it's never been
>> fast-tracked!
> 
> That's not what I mean. Stuff must be reviewed. Review capacity is limited. Some
> stuff gets de-prioritized and reviewed later.
> 
> I managed to review it now, but concluded that it needs more work.
> 
> Instead of reworking the patch now to squeeze it in just before the merge
> window, better to resend this single patch for the next cycle.

I would be ok with pushing the 6 patches that are ready and leave this one for
the next cycle!

@Andrew,

Can you please just drop this patch from the series. I will resubmit once i
handle the feedback provided here.

David,

Thank you for your review, I'll look over the changes you suggested and start
cleaning this up.

Cheers,
-- Nico

>