[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