> On May 7, 2024, at 5:00 AM, David Hildenbrand <david@xxxxxxxxxx> 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
