From: Suren Baghdasaryan <surenb@google.com>
To: Peter Xu <peterx@redhat.com>
Cc: akpm@linux-foundation.org, david@redhat.com, aarcange@redhat.com,
lokeshgidra@google.com, linux-mm@kvack.org,
linux-kernel@vger.kernel.org,
syzbot+b446dbe27035ef6bd6c2@syzkaller.appspotmail.com,
stable@vger.kernel.org
Subject: Re: [PATCH v3 1/1] userfaultfd: fix a crash in UFFDIO_MOVE with some non-present PMDs
Date: Wed, 6 Aug 2025 10:09:30 -0700 [thread overview]
Message-ID: <CAJuCfpGGGJfnvzzdhOEwsXRWPm1nJoPcm2FcrYnkcJtc9W96gA@mail.gmail.com> (raw)
In-Reply-To: <aJOJI-YZ0TTxEzV9@x1.local>
On Wed, Aug 6, 2025 at 9:56 AM Peter Xu <peterx@redhat.com> wrote:
>
> On Wed, Aug 06, 2025 at 08:40:15AM -0700, Suren Baghdasaryan wrote:
> > When UFFDIO_MOVE is used with UFFDIO_MOVE_MODE_ALLOW_SRC_HOLES and it
>
> The migration entry can appear with/without ALLOW_SRC_HOLES, right? Maybe
> drop this line?
Yes, you are right. I'll update.
>
> If we need another repost, the subject can further be tailored to mention
> migration entry too rather than non-present. IMHO that's clearer on
> explaining the issue this patch is fixing (e.g. a valid transhuge THP can
> also have present bit cleared).
>
> > encounters a non-present PMD (migration entry), it proceeds with folio
> > access even though the folio is not present. Add the missing check and
>
> IMHO "... even though folio is not present" is pretty vague. Maybe
> "... even though it's a swap entry"? Fundamentally it's because of the
> different layouts of normal THP v.s. a swap entry, hence pmd_folio() should
> not be used on top of swap entries.
Well, technically a migration entry is a non_swap_entry(), so calling
migration entries "swap entries" is confusing to me. Any better
wording we can use or do you think that's ok?
>
> > let split_huge_pmd() handle migration entries.
> >
> > Fixes: adef440691ba ("userfaultfd: UFFDIO_MOVE uABI")
> > Reported-by: syzbot+b446dbe27035ef6bd6c2@syzkaller.appspotmail.com
> > Closes: https://lore.kernel.org/all/68794b5c.a70a0220.693ce.0050.GAE@google.com/
> > Signed-off-by: Suren Baghdasaryan <surenb@google.com>
> > Cc: stable@vger.kernel.org
> > ---
> > Changes since v2 [1]
> > - Updated the title and changelog, per David Hildenbrand
> > - Removed extra checks for non-present not-migration PMD entries,
> > per Peter Xu
> >
> > [1] https://lore.kernel.org/all/20250731154442.319568-1-surenb@google.com/
> >
> > mm/userfaultfd.c | 17 ++++++++++-------
> > 1 file changed, 10 insertions(+), 7 deletions(-)
> >
> > diff --git a/mm/userfaultfd.c b/mm/userfaultfd.c
> > index 5431c9dd7fd7..116481606be8 100644
> > --- a/mm/userfaultfd.c
> > +++ b/mm/userfaultfd.c
> > @@ -1826,13 +1826,16 @@ ssize_t move_pages(struct userfaultfd_ctx *ctx, unsigned long dst_start,
> > /* Check if we can move the pmd without splitting it. */
> > if (move_splits_huge_pmd(dst_addr, src_addr, src_start + len) ||
> > !pmd_none(dst_pmdval)) {
> > - struct folio *folio = pmd_folio(*src_pmd);
> > -
> > - if (!folio || (!is_huge_zero_folio(folio) &&
> > - !PageAnonExclusive(&folio->page))) {
> > - spin_unlock(ptl);
> > - err = -EBUSY;
> > - break;
> > + /* Can be a migration entry */
> > + if (pmd_present(*src_pmd)) {
> > + struct folio *folio = pmd_folio(*src_pmd);
> > +
> > + if (!folio || (!is_huge_zero_folio(folio) &&
> > + !PageAnonExclusive(&folio->page))) {
> > + spin_unlock(ptl);
> > + err = -EBUSY;
> > + break;
> > + }
> > }
>
> The change itself looks all correct, thanks. If you agree with above
> commit message / subject updates, feel free to take this after some
> amendment of the commit message:
>
> Reviewed-by: Peter Xu <peterx@redhat.com>
>
> >
> > spin_unlock(ptl);
> >
> > base-commit: 8e7e0c6d09502e44aa7a8fce0821e042a6ec03d1
> > --
> > 2.50.1.565.gc32cd1483b-goog
> >
>
> --
> Peter Xu
>
next prev parent reply other threads:[~2025-08-06 17:09 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-06 15:40 Suren Baghdasaryan
2025-08-06 16:56 ` Peter Xu
2025-08-06 17:09 ` Suren Baghdasaryan [this message]
2025-08-06 18:09 ` Peter Xu
2025-08-06 18:21 ` Suren Baghdasaryan
2025-08-06 22:11 ` Suren Baghdasaryan
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=CAJuCfpGGGJfnvzzdhOEwsXRWPm1nJoPcm2FcrYnkcJtc9W96gA@mail.gmail.com \
--to=surenb@google.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lokeshgidra@google.com \
--cc=peterx@redhat.com \
--cc=stable@vger.kernel.org \
--cc=syzbot+b446dbe27035ef6bd6c2@syzkaller.appspotmail.com \
/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