From: Minchan Kim <minchan@kernel.org>
To: Mike Kravetz <mike.kravetz@oracle.com>
Cc: 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>,
David Hildenbrand <david@redhat.com>
Subject: Re: [syzbot] WARNING in follow_hugetlb_page
Date: Sat, 21 May 2022 08:24:00 -0700 [thread overview]
Message-ID: <YokEEAemXTwTSZh5@google.com> (raw)
In-Reply-To: <b36a728c-03a1-0e07-b6d2-9515e647416f@oracle.com>
On Fri, May 20, 2022 at 05:04:22PM -0700, Mike Kravetz wrote:
> On 5/20/22 16:43, Minchan Kim wrote:
> > On Fri, May 20, 2022 at 04:31:31PM -0700, Mike Kravetz wrote:
> >> On 5/20/22 15:56, 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
> >>> pages entirely (via unmounting hugetlbfs, I presume). In
> >>> this case, we now have CMA page that are long-term pinned,
> >>> and that's the state we want to avoid.
> >>
> >> I do not think case 2 can happen. A hugetlb page can only be changed back
> >> to 'normal' (buddy) pages when ref count goes to zero.
> >>
> >> It should also be noted that hugetlb code sets up the CMA area from which
> >> hugetlb pages can be allocated. This area is never unreserved/freed.
> >>
> >> I do not think there is a reason to disallow long term pinning of hugetlb
> >> pages allocated from THE hugetlb CMA area.
> >>
> >> But, I wonder if it is possible for hugetlb pages to be allocated from
> >> another (non-hugetlb) area. For example if someone sets up a huge CMA area
> >> and hugetlb allocations spill over into that area. If this is possible
> >> (still need to research), then we would not want to long term pin such
> >> hugetlb pages. We can check this in the hugetlb code to determine if
> >> long term pinning is allowed.
> >
> > I don't think it's possible because cma_alloc needs "struct cma" just
> > like handle and VM doesn't maintain any fallback list of cma chains
> > so unless someone could steal the handle somehow, there is no way to
> > claim memory others reserved for the CMA purpose.
>
> I was thinking about the case where a hugetlb page is allocated via
> __alloc_pages(). Not sure if that can fall back to a CMA area that
> someone else might have created/reserved.
>
> Unless I do not understand, normal movable memory allocations can fall
> back to CMA areas?
In the case, Yes, it would be fallback if gfp_flag was __GFP_MOVABLE.
If HugeTLB support it(I think so), pin_user_pages with FOLL_LONGTERM
will migrate the page out of movable/CMA before the longterm pinning
so IMHO, we shouldn't have the problem.
__gup_longterm_locked
__get_user_pages_locked
check_and_migrate_movable_pages
> --
> Mike Kravetz
next prev parent reply other threads:[~2022-05-21 15:24 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-13 9:03 [syzbot] WARNING in follow_hugetlb_page syzbot
2022-05-13 16:43 ` syzbot
2022-05-13 17:26 ` Andrew Morton
2022-05-13 18:09 ` Mike Kravetz
2022-05-13 22:48 ` Mike Kravetz
2022-05-13 23:19 ` Andrew Morton
2022-05-13 23:54 ` Minchan Kim
2022-05-14 0:09 ` John Hubbard
2022-05-14 0:26 ` Minchan Kim
2022-05-14 0:56 ` John Hubbard
2022-05-14 1:16 ` John Hubbard
2022-05-17 3:37 ` Mike Kravetz
2022-05-18 7:12 ` John Hubbard
2022-05-20 22:19 ` Minchan Kim
2022-05-20 22:56 ` John Hubbard
2022-05-20 23:25 ` Minchan Kim
2022-05-20 23:31 ` Mike Kravetz
2022-05-20 23:43 ` Minchan Kim
2022-05-21 0:04 ` Mike Kravetz
2022-05-21 15:24 ` Minchan Kim [this message]
2022-05-21 15:51 ` David Hildenbrand
2022-05-21 16:36 ` Minchan Kim
2022-05-21 16:46 ` David Hildenbrand
2022-05-21 18:25 ` Minchan Kim
2022-05-21 23:50 ` Mike Kravetz
2022-05-14 0:18 ` Andrew Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YokEEAemXTwTSZh5@google.com \
--to=minchan@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=jhubbard@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=llvm@lists.linux.dev \
--cc=mike.kravetz@oracle.com \
--cc=nathan@kernel.org \
--cc=ndesaulniers@google.com \
--cc=sfr@canb.auug.org.au \
--cc=syzbot+acf65ca584991f3cc447@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
--cc=trix@redhat.com \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).