Re: [RFC PATCH 0/1] Address hugetlbfs mmap behavior

[Prakash Sangappa <prakash.sangappa@oracle.com>]

> On May 7, 2024, at 5:00 AM, David Hildenbrand <david@redhat.com> wrote:
> 
> On 03.05.24 03:21, Prakash Sangappa wrote:
>> This patch proposes to fix hugetlbfs mmap behavior so that the
>> file size does not get updated in the mmap call.
>> The current behavior is that hugetlbfs file size will get extended by a
>> PROT_WRITE mmap(2) call if mmap size is greater then file size. This is
>> not normal filesystem behavior.
>> There seem to have been very little discussion about this. There was a
>> patch discussion[1] a while back, implying hugetlbfs file size needs
>> extending because of the hugetlb page reservations. Looks like this was
>> not merged.
>> It appears there is no correlation between file size and hugetlb page
>> reservations. Take the case of PROT_READ mmap, where the file size is
>> not extended even though hugetlb pages are reserved.
>> On the other hand ftruncate(2) to increase a file size does not reserve
>> hugetlb pages. Also, mmap with MAP_NORESERVE flag extends the file size
>> even though hugetlb pages are not reserved.
>> Hugetlb pages get reserved(if MAP_NORESERVE is not specified) when the
>> hugeltbfs file is mmapped, and it only covers the file's offset,length
>> range specified in the mmap call.
>> Issue:
>> Some applications would prefer to manage hugetlb page allocations explicity
>> with use of fallocate(2). The hugetlbfs file would be PROT_WRITE mapped with
>> MAP_NORESERVE flag, which is accessed only after allocating necessary pages
>> using fallocate(2) and release the pages by truncating the file size. Any stray
>> access beyond file size is expected to generate a signal. This does not
>> work properly due to current behavior which extends file size in mmap call.
> 
> Would a simple workaround be to mmap(PROT_READ) and then mprotect(PROT_READ|PROT_WRITE)?

Another workaround could be to ftruncate(2) the file after  mmap(PROT_READ|PROT_WRITE), if MAP_NORESERVE is used. But these will require application changes as a special case for hugetlbfs that can be considered. 

However, should this mmap behavior  be addressed? Why mmap(PROT_WRITE) has to extend the file size needs clarification. 

Thanks,
-Prakash 

> 
> I know, not perfect, but certainly better than mount options?
> 
> -- 
> Cheers,
> 
> David / dhildenb