From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Kirill A. Shutemov" Subject: Re: [PATCH] mmap.2: describe the 5level paging hack Date: Tue, 12 Feb 2019 12:41:48 +0300 Message-ID: <20190212094148.qpd6wudyry5vzw3v@kshutemo-mobl1> References: <20190211163653.97742-1-jannh@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20190211163653.97742-1-jannh@google.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Jann Horn Cc: linux-arch@vger.kernel.org, linux-man@vger.kernel.org, Catalin Marinas , Dave Hansen , Peter Zijlstra , Benjamin Herrenschmidt , Will Deacon , linuxppc-dev@lists.ozlabs.org, Andy Lutomirski , linux-mm@kvack.org, Paul Mackerras , mtk.manpages@gmail.com, Michael Ellerman , Andrew Morton , linux-api@vger.kernel.org, Linus Torvalds , Thomas Gleixner , "Kirill A . Shutemov" , linux-arm-kernel@lists.infradead.org List-Id: linux-man@vger.kernel.org On Mon, Feb 11, 2019 at 05:36:53PM +0100, Jann Horn wrote: > The manpage is missing information about the compatibility hack for > 5-level paging that went in in 4.14, around commit ee00f4a32a76 ("x86/mm: > Allow userspace have mappings above 47-bit"). Add some information about > that. > > While I don't think any hardware supporting this is shipping yet (?), I > think it's useful to try to write a manpage for this API, partly to > figure out how usable that API actually is, and partly because when this > hardware does ship, it'd be nice if distro manpages had information about > how to use it. > > Signed-off-by: Jann Horn Thanks for doing this. > --- > This patch goes on top of the patch "[PATCH] mmap.2: fix description of > treatment of the hint" that I just sent, but I'm not sending them in a > series because I want the first one to go in, and I think this one might > be a bit more controversial. > > It would be nice if the architecture maintainers and mm folks could have > a look at this and check that what I wrote is right - I only looked at > the source for this, I haven't tried it. > > man2/mmap.2 | 15 +++++++++++++++ > 1 file changed, 15 insertions(+) > > diff --git a/man2/mmap.2 b/man2/mmap.2 > index 8556bbfeb..977782fa8 100644 > --- a/man2/mmap.2 > +++ b/man2/mmap.2 > @@ -67,6 +67,8 @@ is NULL, > then the kernel chooses the (page-aligned) address > at which to create the mapping; > this is the most portable method of creating a new mapping. > +On Linux, in this case, the kernel may limit the maximum address that can be > +used for allocations to a legacy limit for compatibility reasons. > If > .I addr > is not NULL, > @@ -77,6 +79,19 @@ or equal to the value specified by > and attempt to create the mapping there. > If another mapping already exists there, the kernel picks a new > address, independent of the hint. > +However, if a hint above the architecture's legacy address limit is provided > +(on x86-64: above 0x7ffffffff000, on arm64: above 0x1000000000000, on ppc64 with > +book3s: above 0x7fffffffffff or 0x3fffffffffff, depending on page size), the > +kernel is permitted to allocate mappings beyond the architecture's legacy > +address limit. The availability of such addresses is hardware-dependent. > +Therefore, if you want to be able to use the full virtual address space of > +hardware that supports addresses beyond the legacy range, you need to specify an > +address above that limit; however, for security reasons, you should avoid > +specifying a fixed valid address outside the compatibility range, > +since that would reduce the value of userspace address space layout > +randomization. Therefore, it is recommended to specify an address > +.I beyond > +the end of the userspace address space. It probably worth recommending (void *) -1 as such address. > .\" Before Linux 2.6.24, the address was rounded up to the next page > .\" boundary; since 2.6.24, it is rounded down! > The address of the new mapping is returned as the result of the call. > -- > 2.20.1.791.gb4d0f1c61a-goog > -- Kirill A. Shutemov