Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1190126 > unrolled thread
| Started by | "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> |
|---|---|
| First post | 2015-07-22 19:30 +0200 |
| Last post | 2015-07-23 15:10 +0200 |
| Articles | 2 — 1 participant |
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.
Re: [patch] mmap.2: document the munmap exception for underlying page size "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> - 2015-07-22 19:30 +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:10 +0200
| From | "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> |
|---|---|
| Date | 2015-07-22 19:30 +0200 |
| Subject | Re: [patch] mmap.2: document the munmap exception for underlying page size |
| Message-ID | <pP60d-6bF-47@gated-at.bofh.it> |
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 <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
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/
--
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]
| From | "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> |
|---|---|
| Date | 2015-07-23 15:10 +0200 |
| Message-ID | <pPoq6-7Bj-35@gated-at.bofh.it> |
| In reply to | #1190126 |
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/ -- 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