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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <0C0831EB-AA56-49C9-9D92-460C0FFF9BB5@oracle.com>
Date: Wed, 8 May 2024 17:00:00 +0000
From: Prakash Sangappa <prakash.sangappa@...cle.com>
To: David Hildenbrand <david@...hat.com>
CC: "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>,
        "muchun.song@...ux.dev"
	<muchun.song@...ux.dev>,
        "akpm@...ux-foundation.org"
	<akpm@...ux-foundation.org>,
        "willy@...radead.org" <willy@...radead.org>
Subject: Re: [RFC PATCH 0/1] Address hugetlbfs mmap behavior



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