linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Axel Rasmussen <axelrasmussen@google.com>
To: Peter Xu <peterx@redhat.com>
Cc: Matthew Wilcox <willy@infradead.org>,
	"Vishal Moola (Oracle)" <vishal.moola@gmail.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, akpm@linux-foundation.org,
	Hugh Dickins <hughd@google.com>
Subject: Re: [PATCH 3/5] userfualtfd: Replace lru_cache functions with folio_add functions
Date: Thu, 3 Nov 2022 10:34:38 -0700	[thread overview]
Message-ID: <CAJHvVcj-j6EWm5vQ74Uv1YWHbmg6-BP0hOEO2L9jRADJPEwb1A@mail.gmail.com> (raw)
In-Reply-To: <Y2LWonzCdWkDwyyr@x1n>

On Wed, Nov 2, 2022 at 1:44 PM Peter Xu <peterx@redhat.com> wrote:
>
> On Wed, Nov 02, 2022 at 07:21:19PM +0000, Matthew Wilcox wrote:
> > On Wed, Nov 02, 2022 at 03:02:35PM -0400, Peter Xu wrote:
> > > Does the patch attached look reasonable to you?
> >
> > Mmm, no.  If the page is in the swap cache, this will be "true".
>
> It will not happen in practise, right?
>
> I mean, shmem_get_folio() should have done the swap-in, and we should have
> the page lock held at the meantime.
>
> For anon, mcopy_atomic_pte() is the only user and it's passing in a newly
> allocated page here.
>
> >
> > > diff --git a/mm/userfaultfd.c b/mm/userfaultfd.c
> > > index 3d0fef3980b3..650ab6cfd5f4 100644
> > > --- a/mm/userfaultfd.c
> > > +++ b/mm/userfaultfd.c
> > > @@ -64,7 +64,7 @@ int mfill_atomic_install_pte(struct mm_struct *dst_mm, pmd_t *dst_pmd,
> > >     pte_t _dst_pte, *dst_pte;
> > >     bool writable = dst_vma->vm_flags & VM_WRITE;
> > >     bool vm_shared = dst_vma->vm_flags & VM_SHARED;
> > > -   bool page_in_cache = page->mapping;
> > > +   bool page_in_cache = page_mapping(page);
> >
> > We could do:
> >
> >       struct page *head = compound_head(page);
> >       bool page_in_cache = head->mapping && !PageMappingFlags(head);
>
> Sounds good to me, but it just gets a bit complicated.
>
> If page_mapping() doesn't sound good, how about we just pass that over from
> callers?  We only have three, so quite doable too.

For what it's worth, I think I like Matthew's version better than the
original patch. This is because, although page_mapping() looks simpler
here, looking into the definition of page_mapping() I feel it's
handling several cases, not all of which are relevant here (or, as
Matthew points out, would actually be wrong if it were possible to
reach those cases here).

It's not clear to me what is meant by "pass that over from callers"?
Do you mean, have callers pass in true/false for page_in_cache
directly?

That could work, but I still think I prefer Matthew's version slightly
better, if only because this function already takes a lot of
arguments.

>
> --
> Peter Xu
>

  reply	other threads:[~2022-11-03 17:35 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-01 17:53 [PATCH 0/5] Removing the lru_cache_add() wrapper Vishal Moola (Oracle)
2022-11-01 17:53 ` [PATCH 1/5] filemap: Convert replace_page_cache_page() to replace_page_cache_folio() Vishal Moola (Oracle)
2022-11-01 18:20   ` Matthew Wilcox
2022-11-01 17:53 ` [PATCH 2/5] fuse: Convert fuse_try_move_page() to use folios Vishal Moola (Oracle)
2022-11-01 18:24   ` Matthew Wilcox
2022-11-10 18:36     ` Vishal Moola
2022-11-14 13:25       ` Miklos Szeredi
2022-11-01 17:53 ` [PATCH 3/5] userfualtfd: Replace lru_cache functions with folio_add functions Vishal Moola (Oracle)
2022-11-01 18:31   ` Matthew Wilcox
2022-11-02 19:02     ` Peter Xu
2022-11-02 19:21       ` Matthew Wilcox
2022-11-02 20:44         ` Peter Xu
2022-11-03 17:34           ` Axel Rasmussen [this message]
2022-11-03 17:56             ` Peter Xu
2022-11-02 20:47       ` Andrew Morton
2022-11-01 17:53 ` [PATCH 4/5] khugepage: Replace lru_cache_add() with folio_add_lru() Vishal Moola (Oracle)
2022-11-01 18:32   ` Matthew Wilcox
2022-11-01 17:53 ` [PATCH 5/5] folio-compat: Remove lru_cache_add() Vishal Moola (Oracle)
2022-11-01 18:33   ` Matthew Wilcox
2022-11-29 19:25 ` [PATCH 0/5] Removing the lru_cache_add() wrapper Vishal Moola

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=CAJHvVcj-j6EWm5vQ74Uv1YWHbmg6-BP0hOEO2L9jRADJPEwb1A@mail.gmail.com \
    --to=axelrasmussen@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=hughd@google.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=peterx@redhat.com \
    --cc=vishal.moola@gmail.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;
as well as URLs for NNTP newsgroup(s).