Re: [PATCH] hugetlbfs: add MTE support

[Catalin Marinas <catalin.marinas@arm.com>]

Sorry for the delay (holidays etc.)

On Tue, Jul 09, 2024 at 10:42:58AM -0700, Yang Shi wrote:
> On 7/4/24 6:44 AM, Catalin Marinas wrote:
> > It might be better to convert those page flag checks to only happen on
> > the head page. My stashed changes from over a year ago (before we had
> > more folio conversions) below. However, as I mentioned, I got stuck on
> > folio_copy() which also does a cond_resched() between copy_highpage().
> 
> We can have the page flags set for head only for hugetlb page. For
> copy_highpage(), we should be able to do something like the below:
> 
> if  page_is_head && page_is_hugetlb && page_has_mte_tagged
>     set page_mte_tagged flags
>     copy tags for all sub pages
> else // <-- tail page or non-hugetlb page
>     current copy_highpage implementation

Ah, so you want in the first copy_highpage() for the head page to
populate the tags for the tail pages. I guess this would work.

> The hugetlb folio can't go away under us since migration path should pin it
> so the status of folio is stable. The preemption caused by cond_resched()
> should be fine too due to the pin and the page table entry keeps being
> migration entry until migration is done, so every one should just see
> migration entry and wait for migration is done.

Yeah, I don't see those pages going away, otherwise folio_copy() would
corrupt data.

> The other concerned user of copy_highpage() is uprobe, but it also pins the
> page then doing copy and it is called with holding write mmap_lock.
> 
> IIUC, it should work if I don't miss something. This also should have no
> impact on HVO. The overhead for other users of copy_highpage() should be
> also acceptable.

I also think so. We also have the copy_user_highpage() on arm64 that
calls copy_highpage() but I think that's also safe.

-- 
Catalin