All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rik van Riel <riel@surriel.com>
To: Suren Baghdasaryan <surenb@google.com>
Cc: linux-kernel@vger.kernel.org, kernel-team@meta.com,
	Andrew Morton	 <akpm@linux-foundation.org>,
	David Hildenbrand <david@kernel.org>,
	Jason Gunthorpe <jgg@ziepe.ca>,
	John Hubbard <jhubbard@nvidia.com>, Peter Xu <peterx@redhat.com>,
		linux-mm@kvack.org
Subject: Re: [RFC PATCH v3 4/8] mm/gup: break out follow_one_pte() helper
Date: Fri, 28 Aug 2026 22:11:07 -0400	[thread overview]
Message-ID: <7ba9d2e6370d6134ad34cdffcff5cc79b9192df1.camel@surriel.com> (raw)
In-Reply-To: <CAJuCfpF47Mpi40=8yujBNruCDvY-Ezk0WFEacCqxcdRjmUqt4g@mail.gmail.com>

On Fri, 2026-08-28 at 16:47 -0700, Suren Baghdasaryan wrote:
> On Mon, Aug 10, 2026 at 8:07 PM Rik van Riel <riel@surriel.com>
> wrote:
> > 
> > 
> >         /*
> >          * We only care about anon pages in can_follow_write_pte().
> >          */
> > -       if ((flags & FOLL_WRITE) &&
> > -           !can_follow_write_pte(pte, page, vma, flags)) {
> > -               ret = 0;
> > -               goto out;
> > -       }
> > +       if ((flags & FOLL_WRITE) && !can_follow_write_pte(pte,
> > page, vma, flags))
> > +               return 0;
> 
> Before refactoring in the above case we would "goto out" and
> no_page_table() would not be called even if pte_none(pte). Now I
> think
> you will call it if pte_none(pte). I'm not sure if this does not
> matter but this seems like a functional change.

Good catch, now we may end up calling no_page_table()
on a VMA where we are not allowed to write, for a
FOLL_WRITE access, while before we did not.

That might turn 0 into -EFAULT in some corner cases.

I don't know if we can actually hit any of those
corner cases, or whether they matter in practice,
but the fix seems easy enough, so I'll fix it for v4.

-- 
All Rights Reversed.


  reply	other threads:[~2026-08-29  2:11 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-11  2:51 [RFC PATCH v3 0/8] batch lookups in follow_page_mask() Rik van Riel
2026-08-11  2:51 ` [RFC PATCH v3 1/8] mm/gup: break out gup_fill_pages() helper Rik van Riel
2026-08-28 21:24   ` Suren Baghdasaryan
2026-08-11  2:51 ` [RFC PATCH v3 2/8] mm/gup: convert follow_page_mask() to return a long Rik van Riel
2026-08-28 21:28   ` Suren Baghdasaryan
2026-08-11  2:51 ` [RFC PATCH v3 3/8] mm/gup: split follow_page_pte_commit() out of follow_page_pte() Rik van Riel
2026-08-12 11:50   ` David Hildenbrand (Arm)
2026-08-12 13:02     ` Rik van Riel
2026-08-12 13:23       ` David Hildenbrand (Arm)
2026-08-12 16:19         ` Rik van Riel
2026-08-21 17:38         ` Rik van Riel
2026-08-21 22:04           ` John Hubbard
2026-08-22 13:20             ` Rik van Riel
2026-08-22 21:31               ` John Hubbard
2026-08-24 13:20                 ` Rik van Riel
2026-08-11  2:51 ` [RFC PATCH v3 4/8] mm/gup: break out follow_one_pte() helper Rik van Riel
2026-08-28 23:47   ` Suren Baghdasaryan
2026-08-29  2:11     ` Rik van Riel [this message]
2026-08-11  2:51 ` [RFC PATCH v3 5/8] mm/gup: fill the pages array outside the pud/pmd lock Rik van Riel
2026-08-29  3:00   ` Suren Baghdasaryan
2026-08-11  2:51 ` [RFC PATCH v3 6/8] mm/gup: return a huge page's full count from follow_page_mask() Rik van Riel
2026-08-11  2:51 ` [RFC PATCH v3 7/8] mm/gup: walk multiple PTEs per follow_page_pte() call Rik van Riel
2026-08-29  3:06   ` Suren Baghdasaryan
2026-08-11  2:51 ` [RFC PATCH v3 8/8] mm/gup: batch contiguous same-folio PTEs into one refcount grab Rik van Riel
2026-08-12 11:41 ` [RFC PATCH v3 0/8] batch lookups in follow_page_mask() David Hildenbrand (Arm)
2026-08-25  7:52 ` Christoph Hellwig
2026-08-25 13:37   ` Rik van Riel
2026-08-26  4:39     ` Christoph Hellwig
2026-08-26  7:35       ` Christoph Hellwig
2026-08-26  8:27         ` David Hildenbrand (Arm)
2026-08-26 13:36       ` Rik van Riel

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=7ba9d2e6370d6134ad34cdffcff5cc79b9192df1.camel@surriel.com \
    --to=riel@surriel.com \
    --cc=akpm@linux-foundation.org \
    --cc=david@kernel.org \
    --cc=jgg@ziepe.ca \
    --cc=jhubbard@nvidia.com \
    --cc=kernel-team@meta.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=peterx@redhat.com \
    --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.