Created attachment 303572 [details] Program which demonstrates this issue The vm_unmapped_area function doesn't seem to respect info.low_limit and will sometimes return an address below this limit. This can result in addresses below mmap_min_addr being returned. I bisected it down to this range of commits (I stopped since I was hitting kernel crashes): 3499a13168da mm/mmap: use maple tree for unmapped_area{_topdown} 7fdbd37da5c6 mm/mmap: use the maple tree for find_vma_prev() instead of the rbtree be8432e7166e mm/mmap: use the maple tree in find_vma() instead of the rbtree. 2e3af1db1744 mmap: use the VMA iterator in count_vma_pages_range() f39af05949a4 mm: add VMA iterator d4af56c5c7c6 mm: start tracking VMAs with maple tree I've attached a test program which attempts to allocate the entire address space. On affected kernels, this triggers one of the 2 assertions (depending on whether you are running as root): - NULL is returned, which means memory below mmap_min_addr was allocated. - EPERM is returned, which really shouldn't happen when MAP_FIXED is not used (ENOMEM should be returned instead).
Thanks for the report & the reproducer. This is very helpful. The crash you are hitting in that git id range is actually something I added to ensure I was returning the same value as was being returned before. Although the bug would not be hit until: 3499a13168da mm/mmap: use maple tree for unmapped_area{_topdown} It would have caused a BUG_ON starting in: d4af56c5c7c6 mm: start tracking VMAs with maple tree I will email a fix soon.
Just for completeness, here's a link to the email: https://lore.kernel.org/linux-mm/20230111200136.1851322-1-Liam.Howlett@oracle.com/
I've been consistently slamming into this on 6.1.6 (earliest shipped on Fedora) through 6.2.7. > dex2oatd F 01-18 16:30:44 1390069 1390069 mem_map_arena_pool.cc:65] Check > failed: map.IsValid() Failed anonymous mmap((nil), 131072, 0x3, 0x22, -1, 0): > Cannot allocate memory. See process maps in the log. Using 6.0.18 has been my only workaround. I can report to Red Hat BZ as per policy, but the linked patch above never had any response.
The linked patch landed in 6.1.11 as commit 82587c0e2735 ("maple_tree: fix mas_empty_area_rev() lower bound validation") See the change log here: https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.11 It also landed in v6.2-rc7 as commit 7327e8111adb ("maple_tree: fix mas_empty_area_rev() lower bound validation") Can you provide some more information to recreate your issue?
This looks a lot like a bug reported on the 2nd of march: https://lore.kernel.org/linux-mm/cb8dc31a-fef2-1d09-f133-e9f7b9f9e77a@sony.com/ Although, the flags in this particular mmap does not include the MAP_32BIT flag. The patch for second issue has not made it upstream yet, but is in the mm-unstable and mm-hotfixes-unstable branch. See the link below for the fix for the second issue: https://lore.kernel.org/linux-mm/20230307180247.2220303-1-Liam.Howlett@oracle.com/
Patches introduced in 6.2.13 seemed to have reintroduced the regressions mentioned here: ``` dex2oatd F 05-05 17:46:36 182488 182488 mem_map_arena_pool.cc:65] Check failed: map.IsValid() Failed anonymous mmap((nil), 131072, 0x3, 0x22, -1, 0): Cannot allocate memory. See process maps in the log. ```
There is a fix in mm-unstable that is making its way to fixing this now. https://lore.kernel.org/linux-mm/20230505145829.74574-1-zhangpeng.00@bytedance.com/
(In reply to Liam R. Howlett from comment #7) > There is a fix in mm-unstable that is making its way to fixing this now. > > https://lore.kernel.org/linux-mm/20230505145829.74574-1-zhangpeng. > 00@bytedance.com/ Do you have any idea when it will be entering stable releases? This regression affects all stable, mainline, and 6.1.y LTS
This patch has landed in 6.4-rc3 so it should go to stable shortly