Re: [PATCH] hugetlbfs: add MTE support

[Yang Shi]

On 8/15/24 3:31 AM, Catalin Marinas wrote:
> 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.

Yes, because we know the order of hugetlb page so we know how many tail 
pages we need populate tags for.

A deeper look showed this may be the only way to do it (if we want to 
have mte page flag for head only) because process_huge_page() may 
starting copy from the middle of huge page to have hot sub pages in 
cache. The process_huge_page() is used by hugetlb fork and COW. I think 
it is safe to do so in fork and COW path too since the destination 
hugetlb page won't be seen by the users until fork or COW fault is done.

> > 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.

Yes, it is used by fork and COW fault by hugetlb.

>