From: John Hubbard <jhubbard@nvidia.com> To: Jann Horn <jannh@google.com>, <mtk.manpages@gmail.com>, <linux-man@vger.kernel.org>, <mhocko@kernel.org>, <akpm@linux-foundation.org>, <linux-mm@kvack.org>, <linux-kernel@vger.kernel.org>, <linux-api@vger.kernel.org> Subject: Re: [PATCH] mmap.2: MAP_FIXED is okay if the address range has been reserved Date: Thu, 12 Apr 2018 11:33:04 -0700 [thread overview] Message-ID: <b617740b-fd07-e248-2ba0-9e99b0240594@nvidia.com> (raw) In-Reply-To: <20180412153941.170849-1-jannh@google.com> On 04/12/2018 08:39 AM, Jann Horn wrote: > Clarify that MAP_FIXED is appropriate if the specified address range has > been reserved using an existing mapping, but shouldn't be used otherwise. > > Signed-off-by: Jann Horn <jannh@google.com> > --- > man2/mmap.2 | 19 +++++++++++-------- > 1 file changed, 11 insertions(+), 8 deletions(-) > > diff --git a/man2/mmap.2 b/man2/mmap.2 > index bef8b4432..80c9ec285 100644 > --- a/man2/mmap.2 > +++ b/man2/mmap.2 > @@ -253,8 +253,9 @@ Software that aspires to be portable should use this option with care, > keeping in mind that the exact layout of a process's memory mappings > is allowed to change significantly between kernel versions, > C library versions, and operating system releases. > -Furthermore, this option is extremely hazardous (when used on its own), > -because it forcibly removes preexisting mappings, > +This option should only be used when the specified memory region has > +already been reserved using another mapping; otherwise, it is extremely > +hazardous because it forcibly removes preexisting mappings, > making it easy for a multithreaded process to corrupt its own address space. Yes, that's clearer and provides more information than before. > .IP > For example, suppose that thread A looks through > @@ -284,13 +285,15 @@ and the PAM libraries > .UR http://www.linux-pam.org > .UE . > .IP > -Newer kernels > -(Linux 4.17 and later) have a > +For cases in which the specified memory region has not been reserved using an > +existing mapping, newer kernels (Linux 4.17 and later) provide an option > .B MAP_FIXED_NOREPLACE > -option that avoids the corruption problem; if available, > -.B MAP_FIXED_NOREPLACE > -should be preferred over > -.BR MAP_FIXED . > +that should be used instead; older kernels require the caller to use > +.I addr > +as a hint (without > +.BR MAP_FIXED ) Here, I got lost: the sentence suddenly jumps into explaining non-MAP_FIXED behavior, in the MAP_FIXED section. Maybe if you break up the sentence, and possibly omit non-MAP_FIXED discussion, it will help. > +and take appropriate action if the kernel places the new mapping at a > +different address. > .TP > .BR MAP_FIXED_NOREPLACE " (since Linux 4.17)" > .\" commit a4ff8e8620d3f4f50ac4b41e8067b7d395056843 > thanks, -- John Hubbard NVIDIA
WARNING: multiple messages have this Message-ID (diff)
From: John Hubbard <jhubbard@nvidia.com> To: Jann Horn <jannh@google.com>, mtk.manpages@gmail.com, linux-man@vger.kernel.org, mhocko@kernel.org, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-api@vger.kernel.org Subject: Re: [PATCH] mmap.2: MAP_FIXED is okay if the address range has been reserved Date: Thu, 12 Apr 2018 11:33:04 -0700 [thread overview] Message-ID: <b617740b-fd07-e248-2ba0-9e99b0240594@nvidia.com> (raw) In-Reply-To: <20180412153941.170849-1-jannh@google.com> On 04/12/2018 08:39 AM, Jann Horn wrote: > Clarify that MAP_FIXED is appropriate if the specified address range has > been reserved using an existing mapping, but shouldn't be used otherwise. > > Signed-off-by: Jann Horn <jannh@google.com> > --- > man2/mmap.2 | 19 +++++++++++-------- > 1 file changed, 11 insertions(+), 8 deletions(-) > > diff --git a/man2/mmap.2 b/man2/mmap.2 > index bef8b4432..80c9ec285 100644 > --- a/man2/mmap.2 > +++ b/man2/mmap.2 > @@ -253,8 +253,9 @@ Software that aspires to be portable should use this option with care, > keeping in mind that the exact layout of a process's memory mappings > is allowed to change significantly between kernel versions, > C library versions, and operating system releases. > -Furthermore, this option is extremely hazardous (when used on its own), > -because it forcibly removes preexisting mappings, > +This option should only be used when the specified memory region has > +already been reserved using another mapping; otherwise, it is extremely > +hazardous because it forcibly removes preexisting mappings, > making it easy for a multithreaded process to corrupt its own address space. Yes, that's clearer and provides more information than before. > .IP > For example, suppose that thread A looks through > @@ -284,13 +285,15 @@ and the PAM libraries > .UR http://www.linux-pam.org > .UE . > .IP > -Newer kernels > -(Linux 4.17 and later) have a > +For cases in which the specified memory region has not been reserved using an > +existing mapping, newer kernels (Linux 4.17 and later) provide an option > .B MAP_FIXED_NOREPLACE > -option that avoids the corruption problem; if available, > -.B MAP_FIXED_NOREPLACE > -should be preferred over > -.BR MAP_FIXED . > +that should be used instead; older kernels require the caller to use > +.I addr > +as a hint (without > +.BR MAP_FIXED ) Here, I got lost: the sentence suddenly jumps into explaining non-MAP_FIXED behavior, in the MAP_FIXED section. Maybe if you break up the sentence, and possibly omit non-MAP_FIXED discussion, it will help. > +and take appropriate action if the kernel places the new mapping at a > +different address. > .TP > .BR MAP_FIXED_NOREPLACE " (since Linux 4.17)" > .\" commit a4ff8e8620d3f4f50ac4b41e8067b7d395056843 > thanks, -- John Hubbard NVIDIA
next prev parent reply other threads:[~2018-04-12 18:33 UTC|newest] Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-04-12 15:39 [PATCH] mmap.2: MAP_FIXED is okay if the address range has been reserved Jann Horn 2018-04-12 15:39 ` Jann Horn 2018-04-12 15:39 ` Jann Horn 2018-04-12 18:32 ` Michael Kerrisk (man-pages) 2018-04-12 18:33 ` John Hubbard [this message] 2018-04-12 18:33 ` John Hubbard 2018-04-12 18:37 ` Michael Kerrisk (man-pages) 2018-04-12 18:49 ` Jann Horn 2018-04-12 18:59 ` John Hubbard 2018-04-12 19:18 ` Jann Horn 2018-04-12 19:24 ` John Hubbard 2018-04-13 6:43 ` Michael Kerrisk (man-pages) 2018-04-13 6:49 ` Michal Hocko 2018-04-13 15:04 ` Jann Horn 2018-04-13 16:04 ` Michal Hocko 2018-04-13 16:05 ` Jann Horn 2018-04-13 16:17 ` Jann Horn 2018-04-16 10:07 ` Michal Hocko 2018-04-16 13:55 ` Jann Horn 2018-04-16 19:18 ` Michal Hocko 2018-04-16 19:30 ` Jann Horn 2018-04-16 19:57 ` Michal Hocko 2018-04-16 20:17 ` Jann Horn 2018-04-16 21:11 ` Michal Hocko 2018-04-16 21:12 ` Jann Horn 2018-04-17 6:23 ` Michal Hocko 2018-05-02 13:06 ` Michael Kerrisk (man-pages)
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=b617740b-fd07-e248-2ba0-9e99b0240594@nvidia.com \ --to=jhubbard@nvidia.com \ --cc=akpm@linux-foundation.org \ --cc=jannh@google.com \ --cc=linux-api@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-man@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mhocko@kernel.org \ --cc=mtk.manpages@gmail.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.