From: David Rientjes <rientjes@google.com>
To: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
Cc: Hugh Dickins <hughd@google.com>,
Davide Libenzi <davidel@xmailserver.org>,
Eric B Munson <emunson@akamai.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
linux-man@vger.kernel.org
Subject: Re: [patch] mmap.2: document the munmap exception for underlying page size
Date: Wed, 22 Jul 2015 15:03:18 -0700 (PDT) [thread overview]
Message-ID: <alpine.DEB.2.10.1507221457300.21468@chino.kir.corp.google.com> (raw)
In-Reply-To: <55AFD009.6080706@gmail.com>
On Wed, 22 Jul 2015, Michael Kerrisk (man-pages) wrote:
> > diff --git a/man2/mmap.2 b/man2/mmap.2
> > --- a/man2/mmap.2
> > +++ b/man2/mmap.2
> > @@ -383,6 +383,10 @@ All pages containing a part
> > of the indicated range are unmapped, and subsequent references
> > to these pages will generate
> > .BR SIGSEGV .
> > +An exception is when the underlying memory is not of the native page
> > +size, such as hugetlb page sizes, whereas
> > +.I length
> > +must be a multiple of the underlying page size.
> > It is not an error if the
> > indicated range does not contain any mapped pages.
> > .SS Timestamps changes for file-backed mappings
>
> I'm struggling a bit to understand your text. Is the point this:
>
> If we have a hugetlb area, then the munmap() length
> must be a multiple of the page size.
>
> ?
>
Of the hugetlb page size, yes, which was meant by the "underlying page
size" since we have configurable hugetlb sizes. This is different from
the native page size, whereas the length is rounded up to be page aligned
per POSIX.
> Are there any requirements about 'addr'? Must it also me huge-page-aligned?
>
Yes, so it looks like we need to fix up the reference to "address addr
must be a multiple of the page size" to something like "address addr must
be a multiple of the underlying page size" but I think the distinction
isn't explicit enough as I'd like it. I think it's better to explicitly
show the exception for hugetlb page sizes and compare the underlying page
size to the native page size to define how the behavior differs.
Would something like
An exception is when the underlying memory, such as hugetlb
memory, is not of the native page size: the address addr and
the length must be a multiple of the underlying page size.
suffice?
Also, is it typical to reference the commit of the documentation change
in the kernel source that defines this? I see this done with .\" blocks
for MAP_STACK in the same man page.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2015-07-22 22:03 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-22 0:41 David Rientjes
2015-07-22 17:16 ` Michael Kerrisk (man-pages)
2015-07-22 22:03 ` David Rientjes [this message]
2015-07-23 13:05 ` Michael Kerrisk (man-pages)
2015-07-22 23:31 ` Mike Kravetz
2015-07-22 23:49 ` David Rientjes
2015-07-23 13:15 ` Michael Kerrisk (man-pages)
2015-07-23 20:52 ` David Rientjes
2015-07-24 6:57 ` 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=alpine.DEB.2.10.1507221457300.21468@chino.kir.corp.google.com \
--to=rientjes@google.com \
--cc=davidel@xmailserver.org \
--cc=emunson@akamai.com \
--cc=hughd@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-man@vger.kernel.org \
--cc=linux-mm@kvack.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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox