Re: [syzbot] WARNING in follow_hugetlb_page

From: Minchan Kim <minchan@kernel.org>
To: David Hildenbrand <david@redhat.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>,
	John Hubbard <jhubbard@nvidia.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	syzbot <syzbot+acf65ca584991f3cc447@syzkaller.appspotmail.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	llvm@lists.linux.dev, nathan@kernel.org, ndesaulniers@google.com,
	syzkaller-bugs@googlegroups.com, trix@redhat.com,
	Matthew Wilcox <willy@infradead.org>,
	Stephen Rothwell <sfr@canb.auug.org.au>
Subject: Re: [syzbot] WARNING in follow_hugetlb_page
Date: Sat, 21 May 2022 11:25:00 -0700	[thread overview]
Message-ID: <YokufHxnkHUk5UR6@google.com> (raw)
In-Reply-To: <000a117a-694d-d3a9-a192-14d08d50c884@redhat.com>

On Sat, May 21, 2022 at 06:46:27PM +0200, David Hildenbrand wrote:

< snip >

> >> The general rules are:
> >>
> >> ZONE_MOVABLE: nobody is allowed to place unmovable allocations there; it
> >> could prevent memory offlining/unplug.
> >>
> >> CMA: nobody *but the designated owner* is allowed to place unmovable
> >> memory there; it could prevent the actual owner to allocate contiguous
> >> memory.
> > 
> > I am confused what's the meaning of designated owner and actuall owner
> > in your context.
> 
> designated==actual here. I just wanted to distinguish from someone
> current temporary owner of the page ("allocated it via a movable
> allocation") but the actual designated owner (e.g., hugetlb CMA)
> 
> The page/memory owner terminology is just confusing. Let's rephrase to:
> only the CMA area owner is allowed to place unmovable allocations there.

Yeah, the CMA area owner is much better.

> 
> > 
> > What I thought about the issue based on you explanation:
> > 
> > HugeTLB allocates its page by two types of allocation
> > 
> > 1. alloc_pages(GFP_MOVABLE)
> >  
> > It could allocate the hugetlb page from CMA area but longterm pin
> > should migrate them out of cma before the pinning so allowing
> > the pinning on the page is no problem and current code works like
> > that.
> > 
> >     check_and_migrate_movable_pages
> > 
> 
> Yes.
> 
> > 2. cma_alloc
> > 
> > The cma_alloc is used only for *gigantic page* and the hugetlbfs
> > is the very owner of the page. IOW, if the hugetlbfs was succeeded
> > to allocate the gigantic page by cma_alloc, there is no other
> > owner to be able to claim the page any longer so it's fine to
> > allow longterm pinning againt the gingantic page but current.
> > However, current code doesn't work like that due to
> > is_pinnable_page. IOW, hugetlbfs need a way to distinguish 
> > whether the page owner is hugetlbfs or not.
> > 
> > Are we on same page?
> 
> Yes, exactly. What I wanted to express is: for huge pages we have to
> make a smarter decision because there are cases where we want to
> migrate, and cases where we don't want to migrate.

Sure, maybe hugetlbfs could squeeze a bit in one of subpage of the
CMA compound page. "I am CMA allocated but allow to pinned for longterm"

Thanks.