linux-kernel - Re: [PATCH] x86/mm/vmfault: Make vmalloc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 9 Feb 2016 10:10:03 +0100
From:	Ingo Molnar <mingo@...nel.org>
To:	Toshi Kani <toshi.kani@....com>
Cc:	tglx@...utronix.de, mingo@...hat.com, hpa@...or.com, bp@...en8.de,
	henning.schild@...mens.com, linux-nvdimm@...ts.01.org,
	linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86/mm/vmfault: Make vmalloc_fault() handle large pages


* Toshi Kani <toshi.kani@....com> wrote:

> Since 4.1, ioremap() supports large page (pud/pmd) mappings in x86_64 and PAE.  
> vmalloc_fault() however assumes that the vmalloc range is limited to pte 
> mappings.
> 
> pgd_ctor() sets the kernel's pgd entries to user's during fork(), which makes 
> user processes share the same page tables for the kernel ranges.  When a call to 
> ioremap() is made at run-time that leads to allocate a new 2nd level table (pud 
> in 64-bit and pmd in PAE), user process needs to re-sync with the updated kernel 
> pgd entry with vmalloc_fault().
> 
> Following changes are made to vmalloc_fault().

So what were the effects of this shortcoming? Were large page ioremap()s unusable? 
Was this harmless because no driver used this facility?

If so then the changelog needs to spell this out clearly ...

Thanks,

	Ingo