From: David Hildenbrand <david@redhat.com>
To: Muhammad Usama Anjum <usama.anjum@collabora.com>,
Cyrill Gorcunov <gorcunov@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>
Cc: Nadav Amit <nadav.amit@gmail.com>,
Andrea Arcangeli <aarcange@redhat.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
kernel@collabora.com, Peter Xu <peterx@redhat.com>,
Paul Gofman <pgofman@codeweavers.com>
Subject: Re: [PATCH v4 1/3] mm/mprotect: Fix soft-dirty check in can_change_pte_writable()
Date: Mon, 2 Jan 2023 13:29:37 +0100 [thread overview]
Message-ID: <57f7576b-542b-6ec0-fc5b-5a8c3bed5868@redhat.com> (raw)
In-Reply-To: <40cc5f89-fa10-e107-671e-84bdcf7a4430@collabora.com>
On 28.12.22 15:14, Muhammad Usama Anjum wrote:
> On 12/19/22 5:19 PM, Muhammad Usama Anjum wrote:
>> Addition of vma_soft_dirty_enabled() has tinkered with the soft-dirty PTE
>> bit status setting. The internal behavior has changed. The test case was
>> shared by David
>> (https://lore.kernel.org/all/bfcae708-db21-04b4-0bbe-712badd03071@redhat.com/).
>> The explanation is as following:
>>
>> _Before_ addition of this patch(76aefad628aae),
>> m = mmap(2 pages)
>> clear_softdirty()
>> mremap(m + pag_size)
>> mprotect(READ)
>> mprotect(READ | WRITE);
>> memset(m)
>> After memset(),
>> PAGE-1 PAGE-2
>> VM_SOFTDIRTY set set
>> PTE softdirty flag set set
>> /proc//pagemap view set set
>>
>>
>> _After_ addition of this patch(76aefad628aae)
>> m = mmap(2 pages)
>> clear_softdirty()
>> mremap(m + page_size)
>> mprotect(READ)
>> mprotect(READ | WRITE);
>> memset(m)
>> After memset(),
>> PAGE-1 PAGE-2
>> VM_SOFTDIRTY set set
>> PTE softdirty flag *not set* set
>> /proc//pagemap view set set
>>
>> The user's point of view hasn't changed. But internally after this patch,
>> the soft-dirty tracking in PTEs gets turn off if VM_SOFTDIRTY is set. The
>> soft-dirty tracking in the PTEs shouldn't be just turned off when mprotect
>> is used. Why? Because soft-dirty tracking in the PTEs is always enabled
>> regardless of VM_SOFTDIRTY is set or not. Example:
>>
>> m = mem(2 pages)
>> At this point:
>> PAGE-1 PAGE-2
>> VM_SOFTDIRTY set set
>> PTE softdirty flag not set not set
>> /proc//pagemap view set set
>> memset(m)
>> At this point:
>> PAGE-1 PAGE-2
>> VM_SOFTDIRTY set set
>> PTE softdirty flag set set
>> /proc//pagemap view set set
>>
>> This example proves that soft-dirty flag on the PTE is set regardless of
>> the VM_SOFTDIRTY.
>
> Hi Andrew and Cyrill,
>
> Peter doesn't agree with me here that this change in behavior should be
> reverted etc. Please comment.
For the records, I agree with Peter: As 76aefad628aa ("mm/mprotect: fix
soft-dirty check in can_change_pte_writable()") documents, this patch
fixed real problems.
/proc/pagemap works as expected right now such that we don't have an
under-indication. Internal representation is an implementation detail.
Whatever we do, there must not be an under-indication of softdirty. That
is the ABI guaranteed (especially for anonymous memory). "No
over-indication" was never the ABI guarantee.
For your use case, you want to reduce over-indication. I suggested
looked into alternatives.
--
Thanks,
David / dhildenb
next prev parent reply other threads:[~2023-01-02 12:29 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-25 14:20 [PATCH v4 0/3] mm/mprotect: Fix soft-dirty checks Peter Xu
2022-07-25 14:20 ` [PATCH v4 1/3] mm/mprotect: Fix soft-dirty check in can_change_pte_writable() Peter Xu
2022-11-18 20:16 ` Muhammad Usama Anjum
2022-11-18 23:14 ` Peter Xu
2022-11-21 14:57 ` Muhammad Usama Anjum
2022-11-21 21:17 ` Peter Xu
2022-12-19 12:19 ` Muhammad Usama Anjum
2022-12-20 16:03 ` Peter Xu
2022-12-20 18:15 ` Muhammad Usama Anjum
2022-12-20 19:02 ` Peter Xu
2022-12-21 8:17 ` Muhammad Usama Anjum
2022-12-28 14:14 ` Muhammad Usama Anjum
2023-01-02 12:29 ` David Hildenbrand [this message]
2022-07-25 14:20 ` [PATCH v4 2/3] selftests: soft-dirty: Add test for mprotect Peter Xu
2022-07-25 14:28 ` David Hildenbrand
2022-07-25 14:20 ` [PATCH v4 3/3] selftests: Add soft-dirty into run_vmtests.sh 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=57f7576b-542b-6ec0-fc5b-5a8c3bed5868@redhat.com \
--to=david@redhat.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=gorcunov@gmail.com \
--cc=kernel@collabora.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=nadav.amit@gmail.com \
--cc=peterx@redhat.com \
--cc=pgofman@codeweavers.com \
--cc=usama.anjum@collabora.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