On Wed, Jun 11, 2025 at 11:59:00PM -0700, Nicolin Chen wrote:
We can see the 64MB was rounded up to 512MB by ksys_mmap_pgoff() when being passed in to hugetlb_file_setup() at: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/mm/m... " len = ALIGN(len, huge_page_size(hs)); "
By looking at the comments here..: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/h... " /*
- Note that size should be aligned to proper hugepage size in caller side,
- otherwise hugetlb_reserve_pages reserves one less hugepages than intended.
*/ struct file *hugetlb_file_setup(const char *name, size_t size, "
..I guess this function was supposed to fail the not-a-multiple case as you remarked? But it certainly can't do that, when that size passed in is already hugepage-aligned..
It feels like a kernel bug as you suspect :-/
Certainly is
And I just found one more weird thing...
In iommufd.c selftest code, we have: "static __attribute__((constructor)) void setup_sizes(void)" where it does another pair of posix_memalign/mmap, although this one doesn't flag MAP_HUGETLB and shouldn't impact what is coming to the next...
This could all just be more weirdness from the above, it doesn't really make alot of sense.
I think change things so the MAP_HUGETLB test all skip if HUGEPAGE_SIZE < buffer_size and move on..
Can't run those tests on ARM64 64k which is unfortunate.. I thought there were patches to give that config a 2M huge page size option based on the new contiguous page support though? Maybe it was only THPS..
Jason