Re: [PATCH v2] fs/hugetlbfs/inode.c: Ensure generic_hugetlb_get_unmapped_area() returns higher address than mmap_min_addr

From: Donet Tom
Date: Tue Jul 09 2024 - 09:39:28 EST



On 7/9/24 16:04, Kirill A . Shutemov wrote:
On Tue, Jul 09, 2024 at 04:21:22AM -0500, Donet Tom wrote:
generic_hugetlb_get_unmapped_area() was returning an address less
than mmap_min_addr if the mmap argument addr, after alignment, was
less than mmap_min_addr, causing mmap to fail.

This is because current generic_hugetlb_get_unmapped_area() code does
not take into account mmap_min_addr.

This patch ensures that generic_hugetlb_get_unmapped_area() always returns
an address that is greater than mmap_min_addr. Additionally, similar to
generic_get_unmapped_area(), vm_end_gap() checks are included to ensure
that the address is within the limit.
checks are included to maintain stack gap.
Thank you. I will update and send  V3.

-Donet
How to reproduce
================

#include <stdio.h>
#include <stdlib.h>
#include <sys/mman.h>
#include <unistd.h>

#define HUGEPAGE_SIZE (16 * 1024 * 1024)

int main() {

void *addr = mmap((void *)-1, HUGEPAGE_SIZE,
PROT_READ | PROT_WRITE,
MAP_SHARED | MAP_ANONYMOUS | MAP_HUGETLB, -1, 0);
if (addr == MAP_FAILED) {
perror("mmap");
exit(EXIT_FAILURE);
}

snprintf((char *)addr, HUGEPAGE_SIZE, "Hello, Huge Pages!");

printf("%s\n", (char *)addr);

if (munmap(addr, HUGEPAGE_SIZE) == -1) {
perror("munmap");
exit(EXIT_FAILURE);
}

return 0;
}

Result without fix
==================
# cat /proc/meminfo |grep -i HugePages_Free
HugePages_Free: 20
# ./test
mmap: Permission denied
#

Result with fix
===============
# cat /proc/meminfo |grep -i HugePages_Free
HugePages_Free: 20
# ./test
Hello, Huge Pages!
#

V2:
Added vm_end_gap() check.

V1:
https://lore.kernel.org/all/20240705071150.84972-1-donettom@xxxxxxxxxxxxx/

Reported-by Pavithra Prakash <pavrampu@xxxxxxxxxxxxxxxxxx>
Signed-off-by: Donet Tom <donettom@xxxxxxxxxxxxx>
Please use "hugetlbfs:" as subject prefix. No need to spell out full path.

Otherwise,

Acked-by: Kirill A. Shutemov <kirill.shutemov@xxxxxxxxxxxxxxx>