Re: [PATCH v2 1/3] mm/huge_memory: Fix use of NULL folio in move_pages_huge_pmd()

["David Hildenbrand (Arm)" <david@kernel.org>]

On 3/2/26 18:36, Lorenzo Stoakes wrote:
> On Mon, Mar 02, 2026 at 05:23:30PM +0000, Lorenzo Stoakes wrote:
>>> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
>>> index 44ff8a648afd..fed57951a7cd 100644
>>> --- a/mm/huge_memory.c
>>> +++ b/mm/huge_memory.c
>>> @@ -2794,7 +2794,7 @@ int move_pages_huge_pmd(struct mm_struct *mm, pmd_t *dst_pmd, pmd_t *src_pmd, pm
>>>  		_dst_pmd = pmd_mkwrite(pmd_mkdirty(_dst_pmd), dst_vma);
>>>  	} else {
>>>  		src_pmdval = pmdp_huge_clear_flush(src_vma, src_addr, src_pmd);
>>> -		_dst_pmd = folio_mk_pmd(src_folio, dst_vma->vm_page_prot);
>>> +		_dst_pmd = folio_mk_pmd(page_folio(src_page), dst_vma->vm_page_prot);
>>
>> I prefer my version at [0].
>>
>> Cleaner to actually pull out the zero_folio into a local variable, and also we
>> should mark it special to be consistent with other codepaths.
>>
>> [0]:https://lore.kernel.org/all/20260302170619.867056-1-lorenzo.stoakes@oracle.com/
> 
> OK ignore me, I saw David's comment and agree with him, as I said to you in the
> 2/3, let's just take that as the patch and mark that fixes e3981db444a0.
> 
> Assuming you agree David?

Yes, that's what I suggested I think.

But if Chris is not able to get it done in a timely fashion, maybe you
can take care of it.

I asked something similar in reply to v1:

"Chris, do you have time to follow up, or should I look into it? The
issue looks quite bad, so we should tackle it ASAP."

https://lore.kernel.org/linux-mm/7da49940-e1a4-4018-9db1-208411598e77@kernel.org/

-- 
Cheers,

David