From: Andrea Arcangeli <aarcange@redhat.com>
To: Peter Xu <peterx@redhat.com>
Cc: Hugh Dickins <hughd@google.com>,
Matthew Wilcox <willy@infradead.org>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Andrew Morton <akpm@linux-foundation.org>,
Mike Rapoport <rppt@linux.vnet.ibm.com>,
David Hildenbrand <david@redhat.com>
Subject: Re: [PATCH v2] mm: Don't fault around userfaultfd-registered regions on reads
Date: Fri, 4 Dec 2020 14:37:17 -0500 [thread overview]
Message-ID: <X8qP7QEQTKrhZo57@redhat.com> (raw)
In-Reply-To: <20201204192329.GP108496@xz-x1>
On Fri, Dec 04, 2020 at 02:23:29PM -0500, Peter Xu wrote:
> If we see [1]:
>
> if (!pte_present && !pte_none && pte_swp_uffd_wp && not_anonymous_vma && !is_migration_entry)
>
> Then it's fundamentally the same as:
>
> swp_entry(0, _UFFD_SWP_UFFD_WP) && !vma_is_anonymous(vma)
Yes conceptually it's the same, but in practice it's different value
in the raw pte if you set swp_offset to _UFFD_SWP_UFFD_WP.
Setting swp_offset to _UFFD_SWP_UFFD_WP is just confusing, it's better
magic type 1 offset 0 then to even touch _UFFD_SWP_UFFD_WP if you
reserve the magic value in the swap entry.
pte_swp_uffd_wp or _UFFD_SWP_UFFD_WP are the raw pte value.
swp_entry(0, _UFFD_SWP_UFFD_WP) is not the raw pte value, and it has
to be first converted to the raw pte value with swp_entry_to_pte, so
the _UFFD_SWP_UFFD_WP gets shifted left.
If we use _UFFD_SWP_UFFD_WP it looks much cleaner to keep it in the
pte, not in the swp entry, since then you can use the already existing
methods that only can take in input the pte_t (not the swp_entry_t).
Thanks,
Andrea
next prev parent reply other threads:[~2020-12-04 19:37 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-30 23:06 [PATCH v2] mm: Don't fault around userfaultfd-registered regions on reads Peter Xu
2020-12-01 9:30 ` David Hildenbrand
2020-12-01 12:59 ` Matthew Wilcox
2020-12-01 22:30 ` Peter Xu
2020-12-02 0:02 ` Andrea Arcangeli
2020-12-02 22:37 ` Hugh Dickins
2020-12-02 23:41 ` Peter Xu
2020-12-03 5:36 ` Hugh Dickins
2020-12-03 18:02 ` Peter Xu
2020-12-03 19:44 ` Andrea Arcangeli
2020-12-04 2:30 ` Peter Xu
2020-12-04 4:10 ` Andrea Arcangeli
2020-12-04 5:59 ` Hugh Dickins
2020-12-04 16:50 ` Peter Xu
2020-12-04 18:12 ` Andrea Arcangeli
2020-12-04 19:23 ` Peter Xu
2020-12-04 19:37 ` Andrea Arcangeli [this message]
2020-12-04 20:21 ` Peter Xu
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=X8qP7QEQTKrhZo57@redhat.com \
--to=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=hughd@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=peterx@redhat.com \
--cc=rppt@linux.vnet.ibm.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).