munmap(2) will fail with an errno of EINVAL for hugetlb memory if the
length is not a multiple of the underlying page size.
Documentation/vm/hugetlbpage.txt was updated to specify this behavior
since Linux 4.1 in commit 80d6b94bd69a ("mm, doc: cleanup and clarify
munmap behavior for hugetlb memory").
Signed-off-by: David Rientjes <[email protected]>
---
man2/mmap.2 | 4 ++++
1 file changed, 4 insertions(+)
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
Hi David,
On 07/22/2015 02:41 AM, David Rientjes wrote:
> munmap(2) will fail with an errno of EINVAL for hugetlb memory if the
> length is not a multiple of the underlying page size.
>
> Documentation/vm/hugetlbpage.txt was updated to specify this behavior
> since Linux 4.1 in commit 80d6b94bd69a ("mm, doc: cleanup and clarify
> munmap behavior for hugetlb memory").
>
> Signed-off-by: David Rientjes <[email protected]>
> ---
> man2/mmap.2 | 4 ++++
> 1 file changed, 4 insertions(+)
>
> 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.
?
Are there any requirements about 'addr'? Must it also me huge-page-aligned?
Thanks,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
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.
On 07/21/2015 05:41 PM, David Rientjes wrote:
> munmap(2) will fail with an errno of EINVAL for hugetlb memory if the
> length is not a multiple of the underlying page size.
>
> Documentation/vm/hugetlbpage.txt was updated to specify this behavior
> since Linux 4.1 in commit 80d6b94bd69a ("mm, doc: cleanup and clarify
> munmap behavior for hugetlb memory").
>
> Signed-off-by: David Rientjes <[email protected]>
> ---
> man2/mmap.2 | 4 ++++
> 1 file changed, 4 insertions(+)
>
> 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
>
> --
Should we also add a similar comment for the mmap offset? Currently
the man page says:
"offset must be a multiple of the page size as returned by
sysconf(_SC_PAGE_SIZE)."
For hugetlbfs, I beieve the offset must be a multiple of the
hugetlb page size. A similar comment/exception about using
the "underlying page size" would apply here as well.
--
Mike Kravetz
On Wed, 22 Jul 2015, Mike Kravetz wrote:
> On 07/21/2015 05:41 PM, David Rientjes wrote:
> > munmap(2) will fail with an errno of EINVAL for hugetlb memory if the
> > length is not a multiple of the underlying page size.
> >
> > Documentation/vm/hugetlbpage.txt was updated to specify this behavior
> > since Linux 4.1 in commit 80d6b94bd69a ("mm, doc: cleanup and clarify
> > munmap behavior for hugetlb memory").
> >
> > Signed-off-by: David Rientjes <[email protected]>
> > ---
> > man2/mmap.2 | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > 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
> >
> > --
>
> Should we also add a similar comment for the mmap offset? Currently
> the man page says:
>
> "offset must be a multiple of the page size as returned by
> sysconf(_SC_PAGE_SIZE)."
>
> For hugetlbfs, I beieve the offset must be a multiple of the
> hugetlb page size. A similar comment/exception about using
> the "underlying page size" would apply here as well.
>
Yes, that makes sense, thanks. We should also explicitly say that mmap(2)
automatically aligns length to be hugepage aligned if backed by hugetlbfs.
On 07/23/2015 12:03 AM, David Rientjes wrote:
> 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.
See my suggestion in another mail (in a few minutes).
> 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.
I find it handy to add such references, for later references.
By the way, are you saying that some piece of behavior has
changed in recent times for munmap() on HugeTLB?
Thanks,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
On 07/23/2015 01:49 AM, David Rientjes wrote:
> On Wed, 22 Jul 2015, Mike Kravetz wrote:
>
>> On 07/21/2015 05:41 PM, David Rientjes wrote:
>>> munmap(2) will fail with an errno of EINVAL for hugetlb memory if the
>>> length is not a multiple of the underlying page size.
>>>
>>> Documentation/vm/hugetlbpage.txt was updated to specify this behavior
>>> since Linux 4.1 in commit 80d6b94bd69a ("mm, doc: cleanup and clarify
>>> munmap behavior for hugetlb memory").
>>>
>>> Signed-off-by: David Rientjes <[email protected]>
>>> ---
>>> man2/mmap.2 | 4 ++++
>>> 1 file changed, 4 insertions(+)
>>>
>>> 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
>>>
>>> --
>>
>> Should we also add a similar comment for the mmap offset? Currently
>> the man page says:
>>
>> "offset must be a multiple of the page size as returned by
>> sysconf(_SC_PAGE_SIZE)."
>>
>> For hugetlbfs, I beieve the offset must be a multiple of the
>> hugetlb page size. A similar comment/exception about using
>> the "underlying page size" would apply here as well.
>>
>
> Yes, that makes sense, thanks. We should also explicitly say that mmap(2)
> automatically aligns length to be hugepage aligned if backed by hugetlbfs.
And, surely, it also does something similar for mmap()'s 'addr'
argument?
I suggest we add a subsection to describe the HugeTLB differences. How
about something like:
Huge page (Huge TLB) mappings
For mappings that employ huge pages, the requirements for the
arguments of mmap() and munmap() differ somewhat from the
requirements for mappings that use the native system page size.
For mmap(), offset must be a multiple of the underlying huge page
size. The system automatically aligns length to be a multiple of
the underlying huge page size.
For munmap(), addr and length must both be a multiple of the
underlying huge page size.
?
Thanks,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
On Thu, 23 Jul 2015, Michael Kerrisk (man-pages) wrote:
> >> Should we also add a similar comment for the mmap offset? Currently
> >> the man page says:
> >>
> >> "offset must be a multiple of the page size as returned by
> >> sysconf(_SC_PAGE_SIZE)."
> >>
> >> For hugetlbfs, I beieve the offset must be a multiple of the
> >> hugetlb page size. A similar comment/exception about using
> >> the "underlying page size" would apply here as well.
> >>
> >
> > Yes, that makes sense, thanks. We should also explicitly say that mmap(2)
> > automatically aligns length to be hugepage aligned if backed by hugetlbfs.
>
> And, surely, it also does something similar for mmap()'s 'addr'
> argument?
>
> I suggest we add a subsection to describe the HugeTLB differences. How
> about something like:
>
> Huge page (Huge TLB) mappings
> For mappings that employ huge pages, the requirements for the
> arguments of mmap() and munmap() differ somewhat from the
> requirements for mappings that use the native system page size.
>
> For mmap(), offset must be a multiple of the underlying huge page
> size. The system automatically aligns length to be a multiple of
> the underlying huge page size.
>
> For munmap(), addr and length must both be a multiple of the
> underlying huge page size.
> ?
>
Looks good, please add my acked-by. The commit that expanded on the
documentation of this behavior was
80d6b94bd69a7a49b52bf503ef6a841f43cf5bbb.
Answering from your other email, no, this behavior in the kernel has not
changed recently but we found it wasn't properly documented so we wanted
to fix that both in the kernel tree and in the man-pages to make it
explicit.
Hello David,
On 23 July 2015 at 22:52, David Rientjes <[email protected]> wrote:
> On Thu, 23 Jul 2015, Michael Kerrisk (man-pages) wrote:
>
>> >> Should we also add a similar comment for the mmap offset? Currently
>> >> the man page says:
>> >>
>> >> "offset must be a multiple of the page size as returned by
>> >> sysconf(_SC_PAGE_SIZE)."
>> >>
>> >> For hugetlbfs, I beieve the offset must be a multiple of the
>> >> hugetlb page size. A similar comment/exception about using
>> >> the "underlying page size" would apply here as well.
>> >>
>> >
>> > Yes, that makes sense, thanks. We should also explicitly say that mmap(2)
>> > automatically aligns length to be hugepage aligned if backed by hugetlbfs.
>>
>> And, surely, it also does something similar for mmap()'s 'addr'
>> argument?
>>
>> I suggest we add a subsection to describe the HugeTLB differences. How
>> about something like:
>>
>> Huge page (Huge TLB) mappings
>> For mappings that employ huge pages, the requirements for the
>> arguments of mmap() and munmap() differ somewhat from the
>> requirements for mappings that use the native system page size.
>>
>> For mmap(), offset must be a multiple of the underlying huge page
>> size. The system automatically aligns length to be a multiple of
>> the underlying huge page size.
>>
>> For munmap(), addr and length must both be a multiple of the
>> underlying huge page size.
>> ?
>>
>
> Looks good, please add my acked-by.
Done. Thanks for checking the text.
> The commit that expanded on the
> documentation of this behavior was
> 80d6b94bd69a7a49b52bf503ef6a841f43cf5bbb.
>
> Answering from your other email, no, this behavior in the kernel has not
> changed recently but we found it wasn't properly documented so we wanted
> to fix that both in the kernel tree and in the man-pages to make it
> explicit.
Okay -- thanks for the clarification.
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/