All of lore.kernel.org
 help / color / mirror / Atom feed
From: Foxie Flakey <foxieflakey@gmail.com>
To: Suren Baghdasaryan <surenb@google.com>
Cc: Mike Rapoport <rppt@kernel.org>,
	akpm@linux-foundation.org,  peterx@redhat.com,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] userfaultfd: reset err to be 0 when move_pages_ptes succeeded
Date: Sun, 16 Aug 2026 22:58:13 +0700 (WIB)	[thread overview]
Message-ID: <e75a3269-4298-034c-e35e-ade3998dd88d@gmail.com> (raw)
In-Reply-To: <CAJuCfpGAU+uLDNdcJNKaAG4f0VOoe_3=BSKUC8-Ui4S1gwfDFw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 4424 bytes --]

On Sun, 16 Aug 2026, Suren Baghdasaryan wrote:

> On Sun, Aug 16, 2026 at 2:15 AM Mike Rapoport <rppt@kernel.org> wrote:
> >
> > (adding Suren)
>
> Thanks Mike!
>
> >
> > On Sat, Aug 15, 2026 at 05:42:12PM +0700, Foxie Flakey wrote:
> > >
> > > An fix for edge case can occur if move_pages_ptes return -EAGAIN, later
> > > when checked and it is EAGAIN, outer loop would retry again on same page
> > > and succeeded but the err isn't reset so the outer loop would think need
> > > to retry again so it goes back again and move pages again. On third attempt
> > > move_pages_ptes will fail because it already moved and returns an error
> > > that is not EAGAIN when outer loop checks again it sees non EAGAIN so it
> > > dont retry and break out of loop. When loop is terminated it did not update
> > > the "moved" variable from successful 2nd iteration.
> > >
> > > That behaviour manifested into this at userspace
> > >
> > > Source:      [ .. unmapped  .. ][ .. mapped    ..]
> > > Destination: [ .. mapped    .. ][ .. unmapped  ..]
> > >                           ^     ^
> > >                           \     Kernel moved this far in actuality
> > >                            What is reported to userspace on struct
> > >                            uffdio_move's move field
> > >
> > > When the previous behaviour is
> > > Source:      [ .. unmapped  .. ][ .. mapped    ..]
> > > Destination: [ .. mapped    .. ][ .. unmapped  ..]
> > >                                 ^
> > >                                 Reported to user space via uffdio_move's
> > >                                 move field
>
> This description left me scratching my head. If I understand the
> problem correctly, the issue is that the err is not cleared after we
> decided that we need to retry. If so, how about a simpler explanation:

Sorry for the bad explanation, but that is correct. To repeat again to
make sure I understood correct, move_pages() wrongfully retries to move
again due stale err.

> During move_pages() operation, when move_pages_ptes() returns EAGAIN,
> the error code is not cleared even after we processed it. This leads
> to a successful retry but then the same pages are retried again due to
> the stale error code. This time move fails because pages are already
> moved, loop is terminated and move_pages() reports a failure.
> Clear the error code once we processes EAGAIN.

Thank you, I'll update in v2. I'm waiting for answer from Mike whether
Foxie Flakey is fine in Signed-off-by so I don't create too many revisions
when I can combine feedbacks into one.

> > >
> > > Fixes: 50944692052b ("userfaultfd: opportunistic TLB-flush batching for present pages in MOVE")
> > > Signed-off-by: Foxie Flakey <foxieflakey@gmail.com>
> >
> > Is Foxie Flakey your real name?
> > Signed-off-by should be using a known identity (sorry, no anonymous contributions.)
> >
> > > ---
> > >  mm/userfaultfd.c | 6 ++++--
> > >  1 file changed, 4 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/mm/userfaultfd.c b/mm/userfaultfd.c
> > > index c3adedaaf7d5..595e7e232f90 100644
> > > --- a/mm/userfaultfd.c
> > > +++ b/mm/userfaultfd.c
> > > @@ -2069,10 +2069,12 @@ static ssize_t move_pages(struct userfaultfd_ctx *ctx, unsigned long dst_start,
> > >                       ret = move_pages_ptes(mm, dst_pmd, src_pmd,
> > >                                             dst_vma, src_vma, dst_addr,
> > >                                             src_addr, src_end - src_addr, mode);
> > > -                     if (ret < 0)
> > > +                     if (ret < 0) {
> > >                               err = ret;
> > > -                     else
> > > +                     } else {
> > > +                             err = 0;
> > >                               step_size = ret;
> > > +                     }
>
> This fix is wrong. It resets the err before we process it and
> determine that a retry is needed.
> A proper fix is to reset it later here:
>
> if (err) {
> -        if (err == -EAGAIN)
> +       if (err == -EAGAIN) {
> +              err = 0;
>                continue;
> +       }
>          break;
> }

I see, that one make more sense after thinking about it that retry should
clear err before retrying.

> > >               }
> > >
> > >               cond_resched();
> > >
> > > base-commit: 62cc90241548d5570ee68e01aaba6506964e9811
> > > --
> > > 2.55.0
> > >
> >
> > --
> > Sincerely yours,
> > Mike.
>

      reply	other threads:[~2026-08-16 15:58 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-15 10:42 [PATCH] userfaultfd: reset err to be 0 when move_pages_ptes succeeded Foxie Flakey
2026-08-16  9:15 ` Mike Rapoport
2026-08-16  9:41   ` Foxie Flakey
2026-08-16 11:45     ` Mike Rapoport
2026-08-16 13:58       ` Foxie Flakey
2026-08-16 15:43   ` Suren Baghdasaryan
2026-08-16 15:58     ` Foxie Flakey [this message]

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=e75a3269-4298-034c-e35e-ade3998dd88d@gmail.com \
    --to=foxieflakey@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=peterx@redhat.com \
    --cc=rppt@kernel.org \
    --cc=surenb@google.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 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.