All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Peter Xu <peterx@redhat.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	Andrea Arcangeli <aarcange@redhat.com>,
	Axel Rasmussen <axelrasmussen@google.com>,
	Ives van Hoorne <ives@codesandbox.io>,
	Nadav Amit <nadav.amit@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Mike Rapoport <rppt@linux.vnet.ibm.com>,
	stable@vger.kernel.org
Subject: Re: [PATCH v2 1/2] mm/migrate: Fix read-only page got writable when recover pte
Date: Tue, 15 Nov 2022 19:08:01 +0100	[thread overview]
Message-ID: <dc5a5173-deeb-a6d0-6c2f-5f6f448bf83e@redhat.com> (raw)
In-Reply-To: <Y3PUgOUYx6ECN405@x1n>

On 15.11.22 19:03, Peter Xu wrote:
> On Tue, Nov 15, 2022 at 06:22:03PM +0100, David Hildenbrand wrote:
>> That's precisely what I had in mind recently, and I am happy to hear that
>> you have similar idea:
>>
>> https://lkml.kernel.org/r/20221108174652.198904-6-david@redhat.com
>>
>> "
>> Note that we don't optimize for the actual migration case:
>> (1) When migration succeeds the new PTE will not be writable because the
>>      source PTE was not writable (protnone); in the future we
>>      might just optimize that case similarly by reusing
>>      can_change_pte_writable()/can_change_pmd_writable() when removing
>>      migration PTEs.
>> "
> 
> I see, sorry I haven't yet read it, but sounds doable indeed.
> 
>>
>> Currently, "readable_migration_entry" is even wrong: it might be PROT_NONE
>> and not even readable.
> 
> Do you mean mprotect(PROT_NONE)?
> 
> If we read the "read migration entry" as "migration entry with no write
> bit", it seems still fine, and code-wise after pte recovered it should
> still be PROT_NONE iiuc because mk_pte() will just make a pte without
> e.g. _PRESENT bit set on x86 while it'll have the _PROT_NONE bit.

Exactly that's the unintuitive interpretation of 
"readable_migration_entry". By "wrong" I meant: the naming is wrong.

> 
> May not keep true for numa balancing though: when migration happens after a
> numa hint applied to a pte, it seems to me it's prone to lose the hint
> after migration completes (assuming this migration is not the numa
> balancing operation itself caused by a page access).  Doesn't sound like a
> severe issue though even if I didn't miss something, since if the page got
> moved around the original hint may need to reconsider anyway.

Yes, I think any migration will lose fake PROT_NONE. "Fake" as in "not 
VMA permissions" but "additional permissions imposed by NUMA hinting 
faults."

-- 
Thanks,

David / dhildenb


  reply	other threads:[~2022-11-15 18:09 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-10 20:31 [PATCH v2 0/2] mm/migrate: Fix writable pte for read migration entry Peter Xu
2022-11-10 20:31 ` [PATCH v2 1/2] mm/migrate: Fix read-only page got writable when recover pte Peter Xu
2022-11-10 21:28   ` Nadav Amit
2022-11-10 22:09     ` Peter Xu
2022-11-10 21:53   ` Ives van Hoorne
2022-11-10 22:08     ` Peter Xu
2022-11-10 23:42   ` Alistair Popple
2022-11-13 23:56     ` Peter Xu
2022-11-14  6:22       ` Alistair Popple
2022-11-14 16:09   ` David Hildenbrand
2022-11-14 20:09     ` Peter Xu
2022-11-15  9:13       ` David Hildenbrand
2022-11-15 16:08         ` Peter Xu
2022-11-15 17:22           ` David Hildenbrand
2022-11-15 17:54             ` David Hildenbrand
2022-11-15 18:11               ` Peter Xu
2022-11-15 18:16                 ` David Hildenbrand
2022-11-15 18:03             ` Peter Xu
2022-11-15 18:08               ` David Hildenbrand [this message]
2022-11-10 20:31 ` [PATCH v2 2/2] mm/uffd: Sanity check write bit for uffd-wp protected ptes Peter Xu
2022-11-11 22:06   ` kernel test robot
2022-11-13 22:33     ` Peter Xu
2022-11-12  2:59   ` kernel test robot

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=dc5a5173-deeb-a6d0-6c2f-5f6f448bf83e@redhat.com \
    --to=david@redhat.com \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=axelrasmussen@google.com \
    --cc=ives@codesandbox.io \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=nadav.amit@gmail.com \
    --cc=peterx@redhat.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 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.