Re: [PATCH 2/2] mm: Account for MAP_SHARED mappings using VM_MAYSHARE and not VM_SHARED in hugetlbfs

[Eric B Munson <ebmunson@us.ibm.com>]

[-- Attachment #1: Type: text/plain, Size: 1655 bytes --]

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 <mel@csn.ul.ie>

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 <ebmunson@us.ibm.com>
Tested-by: Eric B Munson <ebmunson@us.ibm.com>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]