From 83e63594e4e82de128f54127032c990672c1988f Mon Sep 17 00:00:00 2001 From: David Rientjes Date: Wed, 8 Apr 2015 09:44:32 +1000 Subject: [PATCH] mm, doc: cleanup and clarify munmap behavior for hugetlb memory fix Don't only specify munmap(2) behavior with respect the hugetlb memory, all other syscalls get naturally aligned to the native page size of the processor. Rather, pick out munmap(2) as a specific example. Signed-off-by: David Rientjes Acked-by: Hugh Dickins Acked-by: Hillf Danton Signed-off-by: Andrew Morton --- Documentation/vm/hugetlbpage.txt | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/Documentation/vm/hugetlbpage.txt b/Documentation/vm/hugetlbpage.txt index 1270fb1ee715..030977fb8d2d 100644 --- a/Documentation/vm/hugetlbpage.txt +++ b/Documentation/vm/hugetlbpage.txt @@ -313,8 +313,11 @@ into /proc/sys/vm/hugetlb_shm_group. It is possible for same or different applications to use any combination of mmaps and shm* calls, though the mount of filesystem will be required for using mmap calls without MAP_HUGETLB. -When using munmap(2) to unmap hugetlb memory, the length specified must be -hugepage aligned, otherwise it will fail with errno set to EINVAL. +Syscalls that operate on memory backed by hugetlb pages only have their lengths +aligned to the native page size of the processor; they will normally fail with +errno set to EINVAL or exclude hugetlb pages that extend beyond the length if +not hugepage aligned. For example, munmap(2) will fail if memory is backed by +a hugetlb page and the length is smaller than the hugepage size. Examples -- 2.39.5