linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alistair Popple <apopple@nvidia.com>
To: Peter Xu <peterx@redhat.com>
Cc: <linux-kernel@vger.kernel.org>, <linux-mm@kvack.org>,
	Axel Rasmussen <axelrasmussen@google.com>,
	"Kirill A . Shutemov" <kirill@shutemov.name>,
	Hugh Dickins <hughd@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Miaohe Lin <linmiaohe@huawei.com>,
	Mike Rapoport <rppt@linux.vnet.ibm.com>,
	Jerome Glisse <jglisse@redhat.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Nadav Amit <nadav.amit@gmail.com>,
	Mike Kravetz <mike.kravetz@oracle.com>,
	Jason Gunthorpe <jgg@ziepe.ca>,
	Matthew Wilcox <willy@infradead.org>
Subject: Re: [PATCH v3 04/27] mm/userfaultfd: Introduce special pte for unmapped file-backed mem
Date: Fri, 28 May 2021 18:32:52 +1000	[thread overview]
Message-ID: <4422901.rTkcW5k3cD@nvdebian> (raw)
In-Reply-To: <20210527201927.29586-5-peterx@redhat.com>

On Friday, 28 May 2021 6:19:04 AM AEST Peter Xu wrote:
> This patch introduces a very special swap-like pte for file-backed memories.
> 
> Currently it's only defined for x86_64 only, but as long as any arch that
> can properly define the UFFD_WP_SWP_PTE_SPECIAL value as requested, it
> should conceptually work too.
> 
> We will use this special pte to arm the ptes that got either unmapped or
> swapped out for a file-backed region that was previously wr-protected.  This
> special pte could trigger a page fault just like swap entries, and as long
> as the page fault will satisfy pte_none()==false && pte_present()==false.
> 
> Then we can revive the special pte into a normal pte backed by the page
> cache.
> 
> This idea is greatly inspired by Hugh and Andrea in the discussion, which is
> referenced in the links below.
> 
> The other idea (from Hugh) is that we use swp_type==1 and swp_offset=0 as
> the special pte.  The current solution (as pointed out by Andrea) is
> slightly preferred in that we don't even need swp_entry_t knowledge at all
> in trapping these accesses.  Meanwhile, we also reuse _PAGE_SWP_UFFD_WP
> from the anonymous swp entries.

So to confirm my understanding the reason you use this special swap pte 
instead of a new swp_type is that you only need the fault and have no extra 
information that needs storing in the pte?

Personally I think it might be better to define a new swp_type for this rather 
than introducing a new arch-specific concept. swp_type entries are portable so 
wouldn't need extra arch-specific bits defined. And as I understand things not 
all architectures (eg. ARM) have spare bits in their swap entry encoding 
anyway so would have to reserve a bit specifically for this which would be 
less efficient than using a swp_type.

Anyway it seems I missed the initial discussion so don't have a strong opinion 
here, mainly just wanted to check my understanding of what's required and how 
these special entries work.

> This patch only introduces the special pte and its operators.  It's not yet
> applied to have any functional difference.
> 
> Link: https://lore.kernel.org/lkml/20201126222359.8120-1-peterx@redhat.com/
> Link: https://lore.kernel.org/lkml/20201130230603.46187-1-peterx@redhat.com/
> Suggested-by: Andrea Arcangeli <aarcange@redhat.com>
> Suggested-by: Hugh Dickins <hughd@google.com>
> Signed-off-by: Peter Xu <peterx@redhat.com>
> ---
>  arch/x86/include/asm/pgtable.h     | 28 ++++++++++++++++++++++++++++
>  include/asm-generic/pgtable_uffd.h |  3 +++
>  include/linux/userfaultfd_k.h      | 21 +++++++++++++++++++++
>  3 files changed, 52 insertions(+)
> 
> diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
> index b1099f2d9800..9781ba2da049 100644
> --- a/arch/x86/include/asm/pgtable.h
> +++ b/arch/x86/include/asm/pgtable.h
> @@ -1329,6 +1329,34 @@ static inline pmd_t pmd_swp_clear_soft_dirty(pmd_t
> pmd) #endif
> 
>  #ifdef CONFIG_HAVE_ARCH_USERFAULTFD_WP
> +
> +/*
> + * This is a very special swap-like pte that marks this pte as
> "wr-protected" + * by userfaultfd-wp.  It should only exist for file-backed
> memory where the + * page (previously got wr-protected) has been unmapped
> or swapped out. + *
> + * For anonymous memories, the userfaultfd-wp _PAGE_SWP_UFFD_WP bit is kept
> + * along with a real swp entry instead.
> + *
> + * Let's make some rules for this special pte:
> + *
> + * (1) pte_none()==false, so that it'll not trigger a missing page fault.
> + *
> + * (2) pte_present()==false, so that it's recognized as swap (is_swap_pte).
> + *
> + * (3) pte_swp_uffd_wp()==true, so it can be tested just like a swap pte
> that + *     contains a valid swap entry, so that we can check a swap pte
> always + *     using "is_swap_pte() && pte_swp_uffd_wp()" without caring
> about whether + *     there's one swap entry inside of the pte.
> + *
> + * (4) It should not be a valid swap pte anywhere, so that when we see this
> pte + *     we know it does not contain a swap entry.
> + *
> + * For x86, the simplest special pte which satisfies all of above should be
> the + * pte with only _PAGE_SWP_UFFD_WP bit set (where
> swp_type==swp_offset==0). + */
> +#define  UFFD_WP_SWP_PTE_SPECIAL  __pte(_PAGE_SWP_UFFD_WP)
> +
>  static inline pte_t pte_swp_mkuffd_wp(pte_t pte)
>  {
>  	return pte_set_flags(pte, _PAGE_SWP_UFFD_WP);
> diff --git a/include/asm-generic/pgtable_uffd.h
> b/include/asm-generic/pgtable_uffd.h index 828966d4c281..95e9811ce9d1
> 100644
> --- a/include/asm-generic/pgtable_uffd.h
> +++ b/include/asm-generic/pgtable_uffd.h
> @@ -2,6 +2,9 @@
>  #define _ASM_GENERIC_PGTABLE_UFFD_H
> 
>  #ifndef CONFIG_HAVE_ARCH_USERFAULTFD_WP
> +
> +#define  UFFD_WP_SWP_PTE_SPECIAL  __pte(0)
> +
>  static __always_inline int pte_uffd_wp(pte_t pte)
>  {
>  	return 0;
> diff --git a/include/linux/userfaultfd_k.h b/include/linux/userfaultfd_k.h
> index 331d2ccf0bcc..93f932b53a71 100644
> --- a/include/linux/userfaultfd_k.h
> +++ b/include/linux/userfaultfd_k.h
> @@ -145,6 +145,17 @@ extern int userfaultfd_unmap_prep(struct vm_area_struct
> *vma, extern void userfaultfd_unmap_complete(struct mm_struct *mm,
>  				       struct list_head *uf);
> 
> +static inline pte_t pte_swp_mkuffd_wp_special(struct vm_area_struct *vma)
> +{
> +	WARN_ON_ONCE(vma_is_anonymous(vma));
> +	return UFFD_WP_SWP_PTE_SPECIAL;
> +}
> +
> +static inline bool pte_swp_uffd_wp_special(pte_t pte)
> +{
> +	return pte_same(pte, UFFD_WP_SWP_PTE_SPECIAL);
> +}
> +
>  #else /* CONFIG_USERFAULTFD */
> 
>  /* mm helpers */
> @@ -234,6 +245,16 @@ static inline void userfaultfd_unmap_complete(struct
> mm_struct *mm, {
>  }
> 
> +static inline pte_t pte_swp_mkuffd_wp_special(struct vm_area_struct *vma)
> +{
> +	return __pte(0);
> +}
> +
> +static inline bool pte_swp_uffd_wp_special(pte_t pte)
> +{
> +	return false;
> +}
> +
>  #endif /* CONFIG_USERFAULTFD */
> 
>  #endif /* _LINUX_USERFAULTFD_K_H */





  reply	other threads:[~2021-05-28  8:33 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-27 20:19 [PATCH v3 00/27] userfaultfd-wp: Support shmem and hugetlbfs Peter Xu
2021-05-27 20:19 ` [PATCH v3 01/27] mm/shmem: Unconditionally set pte dirty in mfill_atomic_install_pte Peter Xu
2021-05-27 20:19 ` [PATCH v3 02/27] shmem/userfaultfd: Take care of UFFDIO_COPY_MODE_WP Peter Xu
2021-05-27 20:19 ` [PATCH v3 03/27] mm: Clear vmf->pte after pte_unmap_same() returns Peter Xu
2021-05-27 20:19 ` [PATCH v3 04/27] mm/userfaultfd: Introduce special pte for unmapped file-backed mem Peter Xu
2021-05-28  8:32   ` Alistair Popple [this message]
2021-05-28 12:56     ` Peter Xu
2021-06-03 11:53       ` Alistair Popple
2021-06-03 14:51         ` Peter Xu
2021-06-04  0:55           ` Alistair Popple
2021-06-04  3:14             ` Hugh Dickins
2021-06-04  6:16               ` Alistair Popple
2021-06-04 16:01                 ` Peter Xu
2021-06-08 13:18                   ` Alistair Popple
2021-06-09 13:06   ` Alistair Popple
2021-06-09 14:43     ` Peter Xu
2021-05-27 20:21 ` [PATCH v3 05/27] mm/swap: Introduce the idea of special swap ptes Peter Xu
2021-05-27 20:21 ` [PATCH v3 06/27] shmem/userfaultfd: Handle uffd-wp special pte in page fault handler Peter Xu
2021-06-17  8:59   ` Alistair Popple
2021-06-17 15:10     ` Peter Xu
2021-05-27 20:21 ` [PATCH v3 07/27] mm: Drop first_index/last_index in zap_details Peter Xu
2021-06-21 12:20   ` Alistair Popple
2021-05-27 20:21 ` [PATCH v3 08/27] mm: Introduce zap_details.zap_flags Peter Xu
2021-06-21 12:09   ` Alistair Popple
2021-06-21 16:16     ` Peter Xu
2021-06-22  2:07       ` Alistair Popple
2021-05-27 20:21 ` [PATCH v3 09/27] mm: Introduce ZAP_FLAG_SKIP_SWAP Peter Xu
2021-06-21 12:36   ` Alistair Popple
2021-06-21 16:26     ` Peter Xu
2021-06-22  2:11       ` Alistair Popple
2021-05-27 20:21 ` [PATCH v3 10/27] mm: Pass zap_flags into unmap_mapping_pages() Peter Xu
2021-05-27 20:22 ` [PATCH v3 11/27] shmem/userfaultfd: Persist uffd-wp bit across zapping for file-backed Peter Xu
2021-06-21  8:41   ` Alistair Popple
2021-06-22  0:40     ` Peter Xu
2021-06-22 12:47       ` Alistair Popple
2021-06-22 15:44         ` Peter Xu
2021-06-23  6:04           ` Alistair Popple
2021-06-23 15:31             ` Peter Xu
2021-07-06  5:40               ` Alistair Popple
2021-07-06 15:35                 ` Peter Xu
2021-07-08  2:49                   ` Alistair Popple
2021-05-27 20:22 ` [PATCH v3 12/27] shmem/userfaultfd: Allow wr-protect none pte for file-backed mem Peter Xu
2021-05-27 20:22 ` [PATCH v3 13/27] shmem/userfaultfd: Allows file-back mem to be uffd wr-protected on thps Peter Xu
2021-05-27 20:22 ` [PATCH v3 14/27] shmem/userfaultfd: Handle the left-overed special swap ptes Peter Xu
2021-05-27 20:22 ` [PATCH v3 15/27] shmem/userfaultfd: Pass over uffd-wp special swap pte when fork() Peter Xu
2021-05-27 20:23 ` [PATCH v3 16/27] mm/hugetlb: Drop __unmap_hugepage_range definition from hugetlb.h Peter Xu
2021-05-27 20:23 ` [PATCH v3 17/27] mm/hugetlb: Introduce huge pte version of uffd-wp helpers Peter Xu
2021-05-27 20:23 ` [PATCH v3 18/27] hugetlb/userfaultfd: Hook page faults for uffd write protection Peter Xu
2021-05-27 20:23 ` [PATCH v3 19/27] hugetlb/userfaultfd: Take care of UFFDIO_COPY_MODE_WP Peter Xu
2021-05-27 20:23 ` [PATCH v3 20/27] hugetlb/userfaultfd: Handle UFFDIO_WRITEPROTECT Peter Xu
2021-05-27 20:23 ` [PATCH v3 21/27] mm/hugetlb: Introduce huge version of special swap pte helpers Peter Xu
2021-05-27 20:23 ` [PATCH v3 22/27] hugetlb/userfaultfd: Handle uffd-wp special pte in hugetlb pf handler Peter Xu
2021-05-27 20:23 ` [PATCH v3 23/27] hugetlb/userfaultfd: Allow wr-protect none ptes Peter Xu
2021-05-27 20:23 ` [PATCH v3 24/27] hugetlb/userfaultfd: Only drop uffd-wp special pte if required Peter Xu
2021-05-27 20:23 ` [PATCH v3 25/27] mm/pagemap: Recognize uffd-wp bit for shmem/hugetlbfs Peter Xu
2021-05-27 20:23 ` [PATCH v3 26/27] mm/userfaultfd: Enable write protection for shmem & hugetlbfs Peter Xu
2021-05-27 20:23 ` [PATCH v3 27/27] userfaultfd/selftests: Enable uffd-wp for shmem/hugetlbfs Peter Xu
2021-06-02 14:40 ` [PATCH v3 00/27] userfaultfd-wp: Support shmem and hugetlbfs Peter Xu
2021-06-02 22:36   ` Andrew Morton
2021-06-03  0:09     ` 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=4422901.rTkcW5k3cD@nvdebian \
    --to=apopple@nvidia.com \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=axelrasmussen@google.com \
    --cc=hughd@google.com \
    --cc=jgg@ziepe.ca \
    --cc=jglisse@redhat.com \
    --cc=kirill@shutemov.name \
    --cc=linmiaohe@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mike.kravetz@oracle.com \
    --cc=nadav.amit@gmail.com \
    --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).