From: David Hildenbrand <david@redhat.com>
To: Dave Hansen <dave.hansen@intel.com>,
Mike Rapoport <rppt@kernel.org>,
linux-mm@kvack.org
Cc: Andrew Morton <akpm@linux-foundation.org>,
Andy Lutomirski <luto@kernel.org>,
Dave Hansen <dave.hansen@linux.intel.com>,
Ira Weiny <ira.weiny@intel.com>,
Kees Cook <keescook@chromium.org>,
Mike Rapoport <rppt@linux.ibm.com>,
Peter Zijlstra <peterz@infradead.org>,
Rick Edgecombe <rick.p.edgecombe@intel.com>,
Vlastimil Babka <vbabka@suse.cz>,
x86@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 4/4] x86/mm: write protect (most) page tables
Date: Wed, 25 Aug 2021 10:38:22 +0200 [thread overview]
Message-ID: <1ec0d015-90fa-e2f4-c9ef-e63ec43a46b3@redhat.com> (raw)
In-Reply-To: <1cccc2b6-8b5b-4aee-483d-f10e64a248a5@intel.com>
On 24.08.21 01:50, Dave Hansen wrote:
> On 8/23/21 6:25 AM, Mike Rapoport wrote:
>> void ___pte_free_tlb(struct mmu_gather *tlb, struct page *pte)
>> {
>> + enable_pgtable_write(page_address(pte));
>> pgtable_pte_page_dtor(pte);
>> paravirt_release_pte(page_to_pfn(pte));
>> paravirt_tlb_remove_table(tlb, pte);
>> @@ -69,6 +73,7 @@ void ___pmd_free_tlb(struct mmu_gather *tlb, pmd_t *pmd)
>> #ifdef CONFIG_X86_PAE
>> tlb->need_flush_all = 1;
>> #endif
>> + enable_pgtable_write(pmd);
>> pgtable_pmd_page_dtor(page);
>> paravirt_tlb_remove_table(tlb, page);
>> }
>
> I would expected this to have leveraged the pte_offset_map/unmap() code
> to enable/disable write access. Granted, it would enable write access
> even when only a read is needed, but that could be trivially fixed with
> having a variant like:
For write access you actually want pte_offset_map_locked(), but it's
also used for stable read access sometimes (exclude any writers).
>
> pte_offset_map_write()
> pte_offset_unmap_write()
>
> in addition to the existing (presumably read-only) versions:
>
> pte_offset_map()
> pte_offset_unmap()
These should mostly only be read access, you'd need other ways of making
sure nobody else messes with that entry. I think it even holds for
khugepaged collapsing code.
I find these hidden PMD entry modifications (e.g., without holding the
PMD lock) deep down in arch code quite concerning. Read: horribly ugly
and a nightmare to debug.
--
Thanks,
David / dhildenb
next prev parent reply other threads:[~2021-08-25 8:38 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-23 13:25 [RFC PATCH 0/4] mm/page_alloc: cache pte-mapped allocations Mike Rapoport
2021-08-23 13:25 ` [RFC PATCH 1/4] list: Support getting most recent element in list_lru Mike Rapoport
2021-08-23 13:25 ` [RFC PATCH 2/4] list: Support list head not in object for list_lru Mike Rapoport
2021-08-23 13:25 ` [RFC PATCH 3/4] mm/page_alloc: introduce __GFP_PTE_MAPPED flag to allocate pte-mapped pages Mike Rapoport
2021-08-23 20:29 ` Edgecombe, Rick P
2021-08-24 13:02 ` Mike Rapoport
2021-08-24 16:38 ` Edgecombe, Rick P
2021-08-24 16:54 ` Mike Rapoport
2021-08-24 17:23 ` Edgecombe, Rick P
2021-08-24 17:37 ` Mike Rapoport
2021-08-24 16:12 ` Vlastimil Babka
2021-08-25 8:43 ` David Hildenbrand
2021-08-23 13:25 ` [RFC PATCH 4/4] x86/mm: write protect (most) page tables Mike Rapoport
2021-08-23 20:08 ` Edgecombe, Rick P
2021-08-23 23:50 ` Dave Hansen
2021-08-24 3:34 ` Andy Lutomirski
2021-08-25 14:59 ` Dave Hansen
2021-08-24 13:32 ` Mike Rapoport
2021-08-25 8:38 ` David Hildenbrand [this message]
2021-08-26 8:02 ` Mike Rapoport
2021-08-26 9:01 ` Vlastimil Babka
2021-08-24 5:32 ` Nadav Amit
2021-08-24 5:34 ` Nadav Amit
2021-08-24 13:36 ` Mike Rapoport
2021-08-23 20:02 ` [RFC PATCH 0/4] mm/page_alloc: cache pte-mapped allocations Edgecombe, Rick P
2021-08-24 13:03 ` Mike Rapoport
2021-08-24 16:09 ` Vlastimil Babka
2021-08-29 7:06 ` Mike Rapoport
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=1ec0d015-90fa-e2f4-c9ef-e63ec43a46b3@redhat.com \
--to=david@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=ira.weiny@intel.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@kernel.org \
--cc=peterz@infradead.org \
--cc=rick.p.edgecombe@intel.com \
--cc=rppt@kernel.org \
--cc=rppt@linux.ibm.com \
--cc=vbabka@suse.cz \
--cc=x86@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.