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

[David Hildenbrand <david@redhat.com>]

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)?

I know, not perfect, but certainly better than mount options?

-- 
Cheers,

David / dhildenb