On Wed, 27 May 2009, Mel Gorman wrote: > hugetlbfs reserves huge pages but does not fault them at mmap() time to ensure > that future faults succeed. The reservation behaviour differs depending on > whether the mapping was mapped MAP_SHARED or MAP_PRIVATE. For MAP_SHARED > mappings, hugepages are reserved when mmap() is first called and are tracked > based on information associated with the inode. Other processes mapping > MAP_SHARED use the same reservation. MAP_PRIVATE track the reservations > based on the VMA created as part of the mmap() operation. Each process > mapping MAP_PRIVATE must make its own reservation. > > hugetlbfs currently checks if a VMA is MAP_SHARED with the VM_SHARED flag and > not VM_MAYSHARE. For file-backed mappings, such as hugetlbfs, VM_SHARED is > set only if the mapping is MAP_SHARED and the file was opened read-write. If a > shared memory mapping was mapped shared-read-write for populating of data and > mapped shared-read-only by other processes, then hugetlbfs would account for > the mapping as if it was MAP_PRIVATE. This causes processes to fail to map > the file MAP_SHARED even though it should succeed as the reservation is there. > > This patch alters mm/hugetlb.c and replaces VM_SHARED with VM_MAYSHARE when > the intent of the code was to check whether the VMA was mapped MAP_SHARED > or MAP_PRIVATE. > > Signed-off-by: Mel Gorman I tested this patch on both x86_64 and ppc64 using 2.6.30-rc7 with the libhugetlbfs test suite and everything looks good. Acked-by: Eric B Munson Tested-by: Eric B Munson