Bug 216911
| Summary: | get_unmapped_area returns addresses below mmap_min_addr | ||
|---|---|---|---|
| Product: | Memory Management | Reporter: | Amanieu d'Antras (amanieu) |
| Component: | Other | Assignee: | Andrew Morton (akpm) |
| Status: | NEW --- | ||
| Severity: | normal | CC: | howlett, nicknitewolf, tad |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | v6.1 | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| Attachments: | Program which demonstrates this issue | ||
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 |
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).