Re: [GIT PULL] arm64 updates for 6.13-rc1

[David Hildenbrand]

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