From: David Hildenbrand <david@redhat.com>
To: Peter Xu <peterx@redhat.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Cc: Andrea Arcangeli <aarcange@redhat.com>,
Pengfei Xu <pengfei.xu@intel.com>,
Nadav Amit <nadav.amit@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
Miaohe Lin <linmiaohe@huawei.com>,
Huang Ying <ying.huang@intel.com>
Subject: Re: [PATCH 2/2] mm: Fix a few rare cases of using swapin error pte marker
Date: Fri, 16 Dec 2022 17:01:09 +0100 [thread overview]
Message-ID: <b3898fb8-3aed-8392-7063-1e58c06d6d5d@redhat.com> (raw)
In-Reply-To: <20221214200453.1772655-3-peterx@redhat.com>
> diff --git a/mm/memory.c b/mm/memory.c
> index 032ef700c3e8..3e836fecd035 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -828,7 +828,7 @@ copy_nonpresent_pte(struct mm_struct *dst_mm, struct mm_struct *src_mm,
> return -EBUSY;
> return -ENOENT;
> } else if (is_pte_marker_entry(entry)) {
> - if (userfaultfd_wp(dst_vma))
> + if (is_swapin_error_entry(entry) || userfaultfd_wp(dst_vma))
> set_pte_at(dst_mm, addr, dst_pte, pte);
As discussed, it would be great if we could in the future avoid such
allow lists and instead have default allow and only handle problematic
cases. Maybe we can do that in the future with selective clearing of
markers.
--
Thanks,
David / dhildenb
next prev parent reply other threads:[~2022-12-16 16:01 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-14 20:04 [PATCH 0/2] mm: Fixes on pte markers Peter Xu
2022-12-14 20:04 ` [PATCH 1/2] mm/uffd: Fix pte marker when fork() without fork event Peter Xu
2022-12-16 9:04 ` David Hildenbrand
2022-12-16 14:54 ` Peter Xu
2022-12-16 15:57 ` David Hildenbrand
2022-12-16 16:24 ` Peter Xu
2022-12-16 16:37 ` David Hildenbrand
2022-12-17 2:59 ` Miaohe Lin
2022-12-14 20:04 ` [PATCH 2/2] mm: Fix a few rare cases of using swapin error pte marker Peter Xu
2022-12-15 7:12 ` Huang, Ying
2022-12-15 14:05 ` Peter Xu
2022-12-16 0:06 ` Huang, Ying
2022-12-16 16:01 ` David Hildenbrand [this message]
2022-12-16 16:04 ` David Hildenbrand
2022-12-17 2:59 ` Miaohe Lin
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=b3898fb8-3aed-8392-7063-1e58c06d6d5d@redhat.com \
--to=david@redhat.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=linmiaohe@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=nadav.amit@gmail.com \
--cc=pengfei.xu@intel.com \
--cc=peterx@redhat.com \
--cc=ying.huang@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox