From: Joerg Roedel <jroedel@suse.de>
To: Andy Lutomirski <luto@kernel.org>
Cc: Joerg Roedel <joro@8bytes.org>, X86 ML <x86@kernel.org>,
"H. Peter Anvin" <hpa@zytor.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Peter Zijlstra <peterz@infradead.org>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
Arnd Bergmann <arnd@arndb.de>,
Andrew Morton <akpm@linux-foundation.org>,
Steven Rostedt <rostedt@goodmis.org>,
Vlastimil Babka <vbabka@suse.cz>,
Michal Hocko <mhocko@kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Linux ACPI <linux-acpi@vger.kernel.org>,
linux-arch <linux-arch@vger.kernel.org>,
Linux-MM <linux-mm@kvack.org>
Subject: Re: [RFC PATCH 0/7] mm: Get rid of vmalloc_sync_(un)mappings()
Date: Sun, 10 May 2020 10:15:16 +0200 [thread overview]
Message-ID: <20200510081516.GX8135@suse.de> (raw)
In-Reply-To: <CALCETrWyQA=4y57PsKhhcRWpxfCufBpda5g7gyEVSST6H5FNJQ@mail.gmail.com>
On Sat, May 09, 2020 at 10:05:43PM -0700, Andy Lutomirski wrote:
> On Sat, May 9, 2020 at 2:57 PM Joerg Roedel <joro@8bytes.org> wrote:
> I spent some time looking at the code, and I'm guessing you're talking
> about the 3-level !SHARED_KERNEL_PMD case. I can't quite figure out
> what's going on.
>
> Can you explain what is actually going on that causes different
> mms/pgds to have top-level entries in the kernel range that point to
> different tables? Because I'm not seeing why this makes any sense.
There are three cases where the PMDs are not shared on x86-32:
1) With non-PAE the top-level is already the PMD level, because
the page-table only has two levels. Since the top-level can't
be shared, the PMDs are also not shared.
2) For some reason Xen-PV also does not share kernel PMDs on PAE
systems, but I havn't looked into why.
3) On 32-bit PAE with PTI enabled the kernel address space
contains the LDT mapping, which is also different per-PGD.
There is one PMD entry reserved for the LDT, giving it 2MB of
address space. I implemented it this way to keep the 32-bit
implementation of PTI mostly similar to the 64-bit one.
> Why does it need to be partitioned at all? The only thing that comes
> to mind is that the LDT range is per-mm. So I can imagine that the
> PAE case with a 3G user / 1G kernel split has to have the vmalloc
> range and the LDT range in the same top-level entry. Yuck.
PAE with 3G user / 1G kernel has _all_ of the kernel mappings in one
top-level entry (direct-mapping, vmalloc, ldt, fixmap).
> If it's *just* the LDT that's a problem, we could plausibly shrink the
> user address range a little bit and put the LDT in the user portion.
> I suppose this could end up creating its own set of problems involving
> tracking which code owns which page tables.
Yeah, for the PTI case it is only the LDT that causes the unshared
kernel PMDs, but even if we move the LDT somewhere else we still have
two-level paging and the xen-pv case.
Joerg
next prev parent reply other threads:[~2020-05-10 8:15 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-08 14:40 [RFC PATCH 0/7] mm: Get rid of vmalloc_sync_(un)mappings() Joerg Roedel
2020-05-08 14:40 ` [RFC PATCH 1/7] mm: Add functions to track page directory modifications Joerg Roedel
2020-05-08 14:40 ` [RFC PATCH 2/7] mm/vmalloc: Track which page-table levels were modified Joerg Roedel
2020-05-08 19:10 ` Peter Zijlstra
2020-05-08 21:23 ` Joerg Roedel
2020-05-08 14:40 ` [RFC PATCH 3/7] mm/ioremap: " Joerg Roedel
2020-05-08 14:40 ` [RFC PATCH 4/7] x86/mm/64: Implement arch_sync_kernel_mappings() Joerg Roedel
2020-05-08 14:40 ` [RFC PATCH 5/7] x86/mm/32: " Joerg Roedel
2020-05-08 14:40 ` [RFC PATCH 6/7] mm: Remove vmalloc_sync_(un)mappings() Joerg Roedel
2020-05-08 18:58 ` Steven Rostedt
2020-05-08 21:24 ` Joerg Roedel
2020-05-08 14:40 ` [RFC PATCH 7/7] x86/mm: Remove vmalloc faulting Joerg Roedel
2020-05-08 19:20 ` [RFC PATCH 0/7] mm: Get rid of vmalloc_sync_(un)mappings() Peter Zijlstra
2020-05-08 21:34 ` Joerg Roedel
2020-05-09 9:25 ` Peter Zijlstra
2020-05-09 17:54 ` Joerg Roedel
2020-05-10 1:11 ` Matthew Wilcox
2020-05-11 7:31 ` Peter Zijlstra
2020-05-11 15:52 ` Matthew Wilcox
2020-05-11 16:08 ` Matthew Wilcox
2020-05-11 17:02 ` Peter Zijlstra
2020-05-08 21:33 ` Andy Lutomirski
2020-05-08 21:36 ` Joerg Roedel
2020-05-08 23:49 ` Andy Lutomirski
2020-05-09 17:52 ` Joerg Roedel
2020-05-09 19:05 ` Andy Lutomirski
2020-05-09 21:57 ` Joerg Roedel
2020-05-10 5:05 ` Andy Lutomirski
2020-05-10 8:15 ` Joerg Roedel [this message]
2020-05-11 7:42 ` Peter Zijlstra
2020-05-11 15:36 ` Andy Lutomirski
2020-05-11 17:06 ` Peter Zijlstra
2020-05-11 19:14 ` Joerg Roedel
2020-05-11 19:36 ` Andy Lutomirski
2020-05-12 15:02 ` Joerg Roedel
2020-05-12 15:13 ` Steven Rostedt
2020-05-11 20:50 ` Steven Rostedt
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=20200510081516.GX8135@suse.de \
--to=jroedel@suse.de \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=joro@8bytes.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@kernel.org \
--cc=mhocko@kernel.org \
--cc=peterz@infradead.org \
--cc=rjw@rjwysocki.net \
--cc=rostedt@goodmis.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).