Re: [RFC PATCH 0/7] mm: Get rid of vmalloc_sync_(un)mappings()

[Andy Lutomirski <luto@amacapital.net>]

> On May 11, 2020, at 12:14 PM, Joerg Roedel <jroedel@suse.de> wrote:
> 
> On Mon, May 11, 2020 at 08:36:31AM -0700, Andy Lutomirski wrote:
>> What if we make 32-bit PTI depend on PAE?
> 
> It already does, PTI support for legacy paging had to be removed because
> there were memory corruption problems with THP. The reason was that huge
> PTEs in the user-space area were mapped in two page-tables (kernel and
> user), but A/D bits were only fetched from the kernel part. To not make
> things more complicated we agreed on just not supporting PTI without
> PAE.
> 
>> And drop 32-bit Xen PV support?  And make 32-bit huge pages depend on
>> PAE?  Then 32-bit non-PAE can use the direct-mapped LDT, 32-bit PTI
>> (and optionally PAE non-PTI) can use the evil virtually mapped LDT.
>> And 32-bit non-PAE (the 2-level case) will only have pointers to page
>> tables at the top level.  And then we can preallocate.
> 
> Not sure I can follow you here. How can 32-bit PTI with PAE use the LDT
> from the direct mapping? I am guessing you want to get rid of the
> SHARED_KERNEL_PMD==0 case for PAE kernels.

I wrote nonsense. I mean bite off a piece of the *user* portion of the address space and stick the LDT there.

I contemplated doing this when I wrote the 64-bit code, but I decided we had so much address space to throw around that I liked my solution better.

> This would indeed make
> syncing unneccessary on PAE, but pre-allocation would still be needed
> for 2-level paging. Just the amount of memory needed for the
> pre-allocated PTE pages is half as big as it would be with PAE.
> 
>> Or maybe we don't want to defeature this much, or maybe the memory hit
>> from this preallocation will hurt little 2-level 32-bit systems too
>> much.
> 
> It will certainly make Linux less likely to boot on low-memory x86-32
> systems, whoever will be affected by this.
> 
> 

I’m guessing the right solution is either your series or your series plus preallocation on 64-bit. I’m just grumpy about it...