From: Jann Horn <email@example.com> To: "Michael Kerrisk (man-pages)" <firstname.lastname@example.org> Cc: linux-arch <email@example.com>, linux-man <firstname.lastname@example.org>, Catalin Marinas <email@example.com>, Linux-MM <firstname.lastname@example.org>, Peter Zijlstra <email@example.com>, Will Deacon <firstname.lastname@example.org>, email@example.com, Andy Lutomirski <firstname.lastname@example.org>, Dave Hansen <email@example.com>, Paul Mackerras <firstname.lastname@example.org>, email@example.com, Andrew Morton <firstname.lastname@example.org>, Linux API <email@example.com>, Linus Torvalds <firstname.lastname@example.org>, Thomas Gleixner <email@example.com>, "Kirill A . Shutemov" <firstname.lastname@example.org> Subject: Re: [PATCH] mmap.2: describe the 5level paging hack Date: Mon, 25 Feb 2019 16:02:48 +0100 Message-ID: <CAG48ez2h6eavM9YWXYa69OLY7mFFKn1KN=roH2dZJCi7PSSmuQ@mail.gmail.com> (raw) In-Reply-To: <email@example.com> On Mon, Feb 25, 2019 at 3:55 PM Michael Kerrisk (man-pages) <firstname.lastname@example.org> wrote: > On 2/11/19 5:36 PM, 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 <email@example.com> > > --- > > 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. > > .\" 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. > > > > Hi Jann, > > A few comments came in on this patch. Is there anything from > those comments that should be rolled into the text? Hi! Yeah, I think all the feedback on the patch were good points, and I'll have to integrate that into my patch.
prev parent reply index Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-02-11 16:36 Jann Horn 2019-02-12 9:41 ` Kirill A. Shutemov 2019-02-13 12:48 ` Will Deacon 2019-02-15 9:13 ` Michael Ellerman 2019-02-25 14:55 ` Michael Kerrisk (man-pages) 2019-02-25 15:02 ` Jann Horn [this message]
Reply instructions: You may reply publically 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='CAG48ez2h6eavM9YWXYa69OLY7mFFKn1KN=roH2dZJCi7PSSmuQ@mail.gmail.com' \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /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
LinuxPPC-Dev Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linuxppc-dev/0 linuxppc-dev/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linuxppc-dev linuxppc-dev/ https://lore.kernel.org/linuxppc-dev \ firstname.lastname@example.org email@example.com firstname.lastname@example.org public-inbox-index linuxppc-dev Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.ozlabs.lists.linuxppc-dev AGPL code for this site: git clone https://public-inbox.org/ public-inbox