Re: [PATCH] mm/huge_memory: avoid transient none PMDs during lazyfree reclaim

[Zi Yan]

On Fri Oct 9, 2026 at 9:12 PM EDT, Lance Yang wrote:
>
>
> On 2026/10/10 04:44, David Hildenbrand (Arm) wrote:
>> On 10/9/26 22:27, Zi Yan wrote:
>>> On 9 Oct 2026, at 16:23, David Hildenbrand (Arm) wrote:
>>>
>>>> On 10/9/26 20:17, Zi Yan wrote:
>>>>>
>>>>> There are some gaps we need to close before getting this fix in:
>>>>>
>>>>> 1. GUP-fast cannot follow the invalidated PMD: riscv and LoongArch need
>>>>> pmd_access_permitted() that requires _PAGE_PRESENT; s390's
>>>>> pmdp_invalidate() needs a change.
>>>>
>>>> Ugh. We really need pmdp_invalidate() to have reasonable semantics. This whole
>>>> PMD locking is a mess :(
>>>>
>>>>>
>>>>> 2. sparc64's thp_pte_count can be imbalanced with this change (based on
>>>>> Lance's offlist feedback).
>>>>
>>>> Ack.
>>>>
>>>>>
>>>>> In addition, powerpc has a page table check issue similr to riscv, where riscv
>>>>> fixed it with commit 9f4a88b8d01a6. This is not related to this issue
>>>>> but discovered along with the investigation.
>>>>
>>>> Zi, do you have the capacity to take over this patch?
>>>
>>> Yes, I can take over it. My plan is to send a series including
>>> patches for 1 and this patch as is. powerpc fix can be a separate one.
>>>
>>> Best Regards,
>>> Yan, Zi
>> 
>> If we need a quick stable fix we could temporarily disable the whole thing until
>> it is fixed, just a thought.
>
> +1 we could do that for now. A quick fix with minimal churn (correctness 
> comes first).

How about the patch below? unmap_huge_pmd_locked() and
__discard_anon_folio_pmd_locked() will be dead code to keep the patch
small. Later, with arch fixes, the function can be re-enabled.