From: Peter Xu <peterx@redhat.com>
To: Nadav Amit <nadav.amit@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Linux-MM <linux-mm@kvack.org>,
Mike Rapoport <rppt@linux.vnet.ibm.com>,
Andrea Arcangeli <aarcange@redhat.com>,
stable@vger.kernel.org
Subject: Re: [PATCH] userfaultfd: mark uffd_wp regardless of VM_WRITE flag
Date: Mon, 21 Feb 2022 14:23:47 +0800 [thread overview]
Message-ID: <YhMv8xAH4+bzSpo2@xz-m1.local> (raw)
In-Reply-To: <68B04C0D-F8CE-4C95-9032-CF703436DC99@gmail.com>
On Thu, Feb 17, 2022 at 08:00:12PM -0800, Nadav Amit wrote:
>
> > On Feb 17, 2022, at 6:23 PM, Nadav Amit <nadav.amit@gmail.com> wrote:
> >
> >> PS: I always think here the VM_SOFTDIRTY check is wrong, IMHO it should be:
> >>
> >> if (dirty_accountable && pte_dirty(ptent) &&
> >> (pte_soft_dirty(ptent) ||
> >> (vma->vm_flags & VM_SOFTDIRTY))) {
> >> ptent = pte_mkwrite(ptent);
> >> }
>
> I know it is off-topic (not directly related to my patch), but
> I tried to understand the logic - both of the existing code and of
> your suggested change - and I failed.
>
> IIUC dirty_accountable (whose value is taken from
> vma_wants_writenotify()) means that the writes *should* be tracked,
> and therefore the page should remain read-only.
Right.
>
> So basically the condition should have been based on
> !dirty_accountable, i.e. the inverted value of dirty_accountable.
>
> The problem is that dirty_accountable also reflects VM_SOFTDIRTY
> considerations, so looking on the PTE does not tell you whether
> the PTE should remain write-protected even if it is dirty.
My understanding is that the dirty bits (especially if both set) means
we've tracked dirty on this pte already so we don't need to, hence we can
set the dirty bit here. E.g., continuous mprotect(RO), mprotect(RW) upon a
full dirty pte.
When something wants to enable tracking again, it needs to clear the dirty
bit, either the real one or soft-dirty one. So it's a pure performance
enhancement to conditionally set write bit here, when we're sure we won't
need any further tracking on this pte.
One thing to mention is that this path only applies to VM_SHARED|VM_WRITE,
because that's what checked the first in vma_wants_writenotify():
/* If it was private or non-writable, the write bit is already clear */
if ((vm_flags & (VM_WRITE|VM_SHARED)) != ((VM_WRITE|VM_SHARED)))
return 0;
IOW private mappings are not optimized in current tree yet.
Peter Collingbourne proposed a patch some time ago to optimize it but it
didn't get merged somehow. Meanwhile even with his latest version it
should still miss the thp case, so if to reference the private optimization
Andrea's tree would be the best:
https://github.com/aagit/aa/commit/fadb5e04d94472614c76819acd979b2f60e4eff6
Hope it clarifies things a bit. Thanks,
--
Peter Xu
next prev parent reply other threads:[~2022-02-21 6:24 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20220217211602.2769-1-namit@vmware.com>
2022-02-17 21:28 ` Nadav Amit
2022-02-18 1:58 ` Peter Xu
2022-02-18 2:23 ` Nadav Amit
2022-02-18 3:56 ` Peter Xu
2022-02-18 4:00 ` Nadav Amit
2022-02-18 4:05 ` Nadav Amit
2022-03-16 22:05 ` Andrew Morton
2022-03-17 0:11 ` Peter Xu
2022-03-17 0:20 ` Andrew Morton
2022-02-21 6:23 ` Peter Xu [this message]
2022-02-28 18:31 ` Nadav Amit
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=YhMv8xAH4+bzSpo2@xz-m1.local \
--to=peterx@redhat.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=linux-mm@kvack.org \
--cc=nadav.amit@gmail.com \
--cc=rppt@linux.vnet.ibm.com \
--cc=stable@vger.kernel.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