From: Alistair Popple <apopple@nvidia.com>
To: <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Hugh Dickins <hughd@google.com>, <linux-mm@kvack.org>,
Peter Xu <peterx@redhat.com>
Cc: Miaohe Lin <linmiaohe@huawei.com>,
David Hildenbrand <david@redhat.com>,
Andrea Arcangeli <aarcange@redhat.com>,
Yang Shi <shy828301@gmail.com>,
Matthew Wilcox <willy@infradead.org>,
"Kirill A . Shutemov" <kirill@shutemov.name>,
Jerome Glisse <jglisse@redhat.com>, <peterx@redhat.com>,
Liam Howlett <liam.howlett@oracle.com>,
Mike Rapoport <rppt@linux.vnet.ibm.com>
Subject: Re: [PATCH v3 5/5] mm: Add ZAP_FLAG_SKIP_SWAP and zap_flags
Date: Wed, 15 Sep 2021 12:25:07 +1000 [thread overview]
Message-ID: <2576475.WBpAVSM2eX@nvdebian> (raw)
In-Reply-To: <20210908163628.215052-1-peterx@redhat.com>
On Thursday, 9 September 2021 2:36:28 AM AEST Peter Xu wrote:
> Firstly, the comment in zap_pte_range() is misleading because it checks against
> details rather than check_mappings, so it's against what the code did.
>
> Meanwhile, there's no explicit reason why passing in the details pointer should
> mean to skip all swap entries. New user of zap_details could very possibly
> miss this fact if they don't read deep until zap_pte_range() because there's no
> comment at zap_details talking about it at all, so swap entries could be
> erroneously skipped without being noticed.
>
> This partly reverts 3e8715fdc03e ("mm: drop zap_details::check_swap_entries"),
> but introduce ZAP_FLAG_SKIP_SWAP flag, which means the opposite of previous
> "details" parameter: the caller should explicitly set this to skip swap
> entries, otherwise swap entries will always be considered (which should still
> be the major case here).
>
> We may want to look into when exactly we need ZAP_FLAG_SKIP_SWAP and we should
> have it in a synchronous manner, e.g., currently even if ZAP_FLAG_SKIP_SWAP is
> set we'll still look into swap pmds no matter what. But that should be a
> separate effort of this patch.
I didn't really follow what you mean by "synchronous" here, although the
explanation about pmds makes sense so it's probably just terminology.
> The flag introduced in this patch will be a preparation for more bits defined
> in the future, e.g., for a new bit in flag to show whether to persist the
> upcoming uffd-wp bit in pgtable entries.
That's kind of the problem. The patch itself looks correct to me however as
mentioned it is mostly reverting a previous cleanup and it's hard to tell why
that's justified without the subsequent patches. Perhaps it makes the usage of
zap_details a bit clearer, but a comment also would with less code.
I know you want to try and shrink the uffd-wp series but I think this patch
might be easier to review if it was included as part of that series.
> Cc: Kirill A. Shutemov <kirill@shutemov.name>
> Cc: Hugh Dickins <hughd@google.com>
> Signed-off-by: Peter Xu <peterx@redhat.com>
> ---
> include/linux/mm.h | 16 ++++++++++++++++
> mm/memory.c | 6 +++---
> 2 files changed, 19 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index ed44f31615d9..beb784ce35b9 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -1717,12 +1717,18 @@ static inline bool can_do_mlock(void) { return false; }
> extern int user_shm_lock(size_t, struct ucounts *);
> extern void user_shm_unlock(size_t, struct ucounts *);
>
> +typedef unsigned int __bitwise zap_flags_t;
> +
> +/* Whether to skip zapping swap entries */
> +#define ZAP_FLAG_SKIP_SWAP ((__force zap_flags_t) BIT(0))
> +
> /*
> * Parameter block passed down to zap_pte_range in exceptional cases.
> */
> struct zap_details {
> struct address_space *zap_mapping; /* Check page->mapping if set */
> struct page *single_page; /* Locked page to be unmapped */
> + zap_flags_t zap_flags; /* Extra flags for zapping */
> };
>
> /*
> @@ -1739,6 +1745,16 @@ zap_skip_check_mapping(struct zap_details *details, struct page *page)
> (details->zap_mapping != page_rmapping(page));
> }
>
> +/* Return true if skip swap entries, false otherwise */
> +static inline bool
> +zap_skip_swap(struct zap_details *details)
> +{
> + if (!details)
> + return false;
> +
> + return details->zap_flags & ZAP_FLAG_SKIP_SWAP;
> +}
> +
> struct page *vm_normal_page(struct vm_area_struct *vma, unsigned long addr,
> pte_t pte);
> struct page *vm_normal_page_pmd(struct vm_area_struct *vma, unsigned long addr,
> diff --git a/mm/memory.c b/mm/memory.c
> index e5ee8399d270..26e37bef1888 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -1379,8 +1379,7 @@ static unsigned long zap_pte_range(struct mmu_gather *tlb,
> continue;
> }
>
> - /* If details->check_mapping, we leave swap entries. */
> - if (unlikely(details))
> + if (unlikely(zap_skip_swap(details)))
> continue;
>
> if (!non_swap_entry(entry))
> @@ -3353,6 +3352,7 @@ void unmap_mapping_page(struct page *page)
>
> details.zap_mapping = mapping;
> details.single_page = page;
> + details.zap_flags = ZAP_FLAG_SKIP_SWAP;
>
> i_mmap_lock_write(mapping);
> if (unlikely(!RB_EMPTY_ROOT(&mapping->i_mmap.rb_root)))
> @@ -3377,7 +3377,7 @@ void unmap_mapping_pages(struct address_space *mapping, pgoff_t start,
> pgoff_t nr, bool even_cows)
> {
> pgoff_t first_index = start, last_index = start + nr - 1;
> - struct zap_details details = { };
> + struct zap_details details = { .zap_flags = ZAP_FLAG_SKIP_SWAP };
>
> details.zap_mapping = even_cows ? NULL : mapping;
> if (last_index < first_index)
>
next prev parent reply other threads:[~2021-09-15 2:25 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-08 16:35 [PATCH v3 0/5] mm: A few cleanup patches around zap, shmem and uffd Peter Xu
2021-09-08 16:35 ` [PATCH v3 1/5] mm/shmem: Unconditionally set pte dirty in mfill_atomic_install_pte Peter Xu
2021-09-08 16:36 ` [PATCH v3 2/5] mm: Clear vmf->pte after pte_unmap_same() returns Peter Xu
2021-09-08 16:36 ` [PATCH v3 3/5] mm: Drop first_index/last_index in zap_details Peter Xu
2021-09-09 2:54 ` Liam Howlett
2021-09-09 18:13 ` Peter Xu
2021-09-08 16:36 ` [PATCH v3 4/5] mm: Add zap_skip_check_mapping() helper Peter Xu
2021-09-09 1:16 ` Alistair Popple
2021-09-08 16:36 ` [PATCH v3 5/5] mm: Add ZAP_FLAG_SKIP_SWAP and zap_flags Peter Xu
2021-09-15 2:25 ` Alistair Popple [this message]
2021-09-15 2:52 ` Peter Xu
2021-09-15 3:21 ` Alistair Popple
2021-09-15 4:01 ` Peter Xu
2021-09-14 16:37 ` [PATCH v3 0/5] mm: A few cleanup patches around zap, shmem and uffd 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=2576475.WBpAVSM2eX@nvdebian \
--to=apopple@nvidia.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=hughd@google.com \
--cc=jglisse@redhat.com \
--cc=kirill@shutemov.name \
--cc=liam.howlett@oracle.com \
--cc=linmiaohe@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=peterx@redhat.com \
--cc=rppt@linux.vnet.ibm.com \
--cc=shy828301@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 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.