[GIT PULL] arm64 updates for 6.13-rc1

David Hildenbrand david at redhat.com
Thu Nov 28 01:56:32 PST 2024


On 28.11.24 02:21, Yang Shi wrote:
>>> diff --git a/arch/arm64/mm/copypage.c b/arch/arm64/mm/copypage.c
>>> index 87b3f1a25535..ef303a2262c5 100644
>>> --- a/arch/arm64/mm/copypage.c
>>> +++ b/arch/arm64/mm/copypage.c
>>> @@ -30,9 +30,9 @@ void copy_highpage(struct page *to, struct page *from)
>>>     	if (!system_supports_mte())
>>>     		return;
>>> -	if (folio_test_hugetlb(src) &&
>>> -	    folio_test_hugetlb_mte_tagged(src)) {
>>> -		if (!folio_try_hugetlb_mte_tagging(dst))
>>> +	if (folio_test_hugetlb(src)) {
>>> +		if (!folio_test_hugetlb_mte_tagged(src) ||
>>> +		    !folio_try_hugetlb_mte_tagging(dst))
>>>     			return;
>>>     		/*
>> I wonder why we had a 'return' here originally rather than a
>> WARN_ON_ONCE() as we do further down for the page case. Do you seen any
>> issue with the hunk below? Destination should be a new folio and not
>> tagged yet:
> 
> Yes, I did see problem. Because we copy tags for all sub pages then set
> folio mte tagged when copying the data for the first subpage. The
> warning will be triggered when we copy the second subpage.

It's rather weird, though. We're instructed to copy a single page, yet 
copy tags for all pages.

This really only makes sense when called from folio_copy(), where we are 
guaranteed to copy all pages.

I'm starting to wonder if we should be able to hook into / overload 
folio_copy() instead, to just handle the complete hugetlb copy ourselves 
in one shot, and assume that copy_highpage() will never be called for 
hugetlb pages (WARN and don't copy tags).

-- 
Cheers,

David / dhildenb




More information about the linux-arm-kernel mailing list