Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1190357 > unrolled thread

Re: [patch] mmap.2: document the munmap exception for underlying page size

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [patch] mmap.2: document the munmap exception for underlying  page size Mike Kravetz <mike.kravetz@oracle.com> - 2015-07-23 01:40 +0200
    Re: [patch] mmap.2: document the munmap exception for underlying  page size David Rientjes <rientjes@google.com> - 2015-07-23 01:50 +0200
      Re: [patch] mmap.2: document the munmap exception for underlying  page size "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> - 2015-07-23 15:20 +0200

#1190357 — Re: [patch] mmap.2: document the munmap exception for underlying page size

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 <rientjes@google.com>
> ---
>   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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1190364

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 <rientjes@google.com>
> > ---
> >   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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1190913

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 <rientjes@google.com>
>>> ---
>>>   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/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web