Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
Sender: Minchan Kim <minchan.kim@gmail.com>
Date:   Fri, 20 May 2022 16:25:06 -0700
From:   Minchan Kim <minchan@kernel.org>
To:     John Hubbard <jhubbard@nvidia.com>
Cc:     Mike Kravetz <mike.kravetz@oracle.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>,
        David Hildenbrand <david@redhat.com>
Subject: Re: [syzbot] WARNING in follow_hugetlb_page
Message-ID: <YogjUl1IshuqVkjs@google.com>
References: <75f09063-d184-7d44-17a1-ed04be5eb953@oracle.com>
 <a7fd0c3f-921e-19b3-2f67-a231dede28f9@oracle.com>
 <20220513161910.d1b73583cdb2e33562aa86e5@linux-foundation.org>
 <Yn7vnpXwX50J3K+7@google.com>
 <4809b134-a37a-50b8-4c25-44548bc1048f@nvidia.com>
 <Yn73Hz7LkSUv7ycw@google.com>
 <d97d8a00-e9e0-278f-0c3f-71162afa48b1@nvidia.com>
 <6d281052-485c-5e17-4f1c-ef5689831450@oracle.com>
 <YogT9AwVclxAnyvs@google.com>
 <0be9132d-a928-9ebe-a9cf-6d140b907d59@nvidia.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <0be9132d-a928-9ebe-a9cf-6d140b907d59@nvidia.com>
Precedence: bulk

On Fri, May 20, 2022 at 03:56:31PM -0700, John Hubbard wrote:
> On 5/20/22 15:19, Minchan Kim wrote:
> > The memory offline would be an issue so we shouldn't allow pinning of any
> > pages in *movable zone*.
> > 
> > Isn't alloc_contig_range just best effort? Then, it wouldn't be a big
> > problem to allow pinning on those area. The matter is what target range
> > on alloc_contig_range is backed by CMA or movable zone and usecases.
> > 
> > IOW, movable zone should be never allowed. But CMA case, if pages
> > are used by normal process memory instead of hugeTLB, we shouldn't
> > allow longterm pinning since someone can claim those memory suddenly.
> > However, we are fine to allow longterm pinning if the CMA memory
> > already claimed and mapped at userspace(hugeTLB case IIUC).
> > 
> 
> From Mike's comments and yours, plus a rather quick reading of some
> CMA-related code in mm/hugetlb.c (free_gigantic_page(),
> alloc_gigantic_pages()), the following seems true:
> 
> a) hugetlbfs can allocate pages *from* CMA, via cma_alloc()
> 
> b) while hugetlbfs is using those CMA-allocated pages, it is debatable
> whether those pages should be allowed to be long term pinned. That's
> because there are two cases:
> 
>     Case 1: pages are longterm pinned, then released, all while
>             owned by hugetlbfs. No problem.
> 
>     Case 2: pages are longterm pinned, but then hugetlbfs releases the

Longterm pinned means the hugetlbfs page were mapped at userspace and
someone called FOLL_LONGTERM against on the page?

>             pages entirely (via unmounting hugetlbfs, I presume). In

Then, how can FS unmount successfully while something is accessing
on the page of the file in FS? (I expected FS should return -EBUSY).
Does hugetlbfs have something special?


>             this case, we now have CMA page that are long-term pinned,
>             and that's the state we want to avoid.