linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: John Hubbard <jhubbard@nvidia.com>
To: Minchan Kim <minchan@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Mike Kravetz <mike.kravetz@oracle.com>,
	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: Fri, 13 May 2022 17:56:59 -0700	[thread overview]
Message-ID: <d97d8a00-e9e0-278f-0c3f-71162afa48b1@nvidia.com> (raw)
In-Reply-To: <Yn73Hz7LkSUv7ycw@google.com>

On 5/13/22 17:26, Minchan Kim wrote:
> Anything else further can we get insight from the warning?
> 
> For example, pin_user_pages going on against a hugetlb page
> which are concurrently running alloc_contig_range(it's
> exported function so anyone can call randomly) so
> alloc_contig_range changes pageblock type as MIGRATE_ISOLATE
> under us so the hit at the warning?

Well, yes. First of all, the comments above the warning that fired have
gone a little bit stale: they claim that we can only hit the warning if
the page refcount overflows. However, we almost certainly got here via:

try_grab_folio()
	/*
	 * Can't do FOLL_LONGTERM + FOLL_PIN gup fast path if not in a
	 * right zone, so fail and let the caller fall back to the slow
	 * path.
	 */
	if (unlikely((flags & FOLL_LONGTERM) &&
		     !is_pinnable_page(page))) /* which we just changed */
		return NULL;

...and now I'm starting to think that this warning might fire even with
the corrected check for MIGRATE_CMA || MIGRATE_ISOLATE. Because
try_grab_folio() didn't always have this early exit and it is starting
to look wrong.

Simply attempting to pin a non-pinnable huge page would hit this
warning. Adding additional reasons that a page is not pinnable (which
the patch does) could make this more likely to fire.

I need to look at this a little more closely, it is making me wonder
whether the is_pinnable_page() check is a problem in this path. The
comment in try_grab_folio() indicates that the early return is a hack
(it assumes that the caller is in the gup fast path), and maybe the hack
is just wrong here--I think we're actually on the slow gup path. Not
good.

Mike, any thoughts here?



thanks,
-- 
John Hubbard
NVIDIA


  reply	other threads:[~2022-05-14  0:57 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-13  9:03 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 [this message]
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
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=d97d8a00-e9e0-278f-0c3f-71162afa48b1@nvidia.com \
    --to=jhubbard@nvidia.com \
    --cc=akpm@linux-foundation.org \
    --cc=david@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=llvm@lists.linux.dev \
    --cc=mike.kravetz@oracle.com \
    --cc=minchan@kernel.org \
    --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