All of lore.kernel.org
 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] 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 [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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.