Hi, I noticed a regression report in bugzilla.kernel.org. As many
(most?) kernel developer don't keep an eye on it, I decided to forward
it by mail. Quoting from
https://bugzilla.kernel.org/show_bug.cgi?id=216911 :
> Amanieu d'Antras 2023-01-11 02:10:02 UTC
>
> 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
[those are all from the Maple Tree introduction series]
> 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).
See the ticket for more details.
BTW, let me use this mail to also add the report to the list of tracked
regressions to ensure it's doesn't fall through the cracks:
#regzbot introduced: d4af56c5c7c6..3499a13168da
https://bugzilla.kernel.org/show_bug.cgi?id=216911
#regzbot title: mm: get_unmapped_area returns addresses below mmap_min_addr
#regzbot ignore-activity
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.
[resent with akpm's proper email address (either me or my mailer did
something stupid; sorry for the noise)]
On 11.01.23 11:46, Linux kernel regression tracking (Thorsten Leemhuis)
wrote:
> Hi, I noticed a regression report in bugzilla.kernel.org. As many
> (most?) kernel developer don't keep an eye on it, I decided to forward
> it by mail. Quoting from
> https://bugzilla.kernel.org/show_bug.cgi?id=216911 :
>
>> Amanieu d'Antras 2023-01-11 02:10:02 UTC
>>
>> 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
>
> [those are all from the Maple Tree introduction series]
>
>> 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).
>
> See the ticket for more details.
>
> BTW, let me use this mail to also add the report to the list of tracked
> regressions to ensure it's doesn't fall through the cracks:
>
> #regzbot introduced: d4af56c5c7c6..3499a13168da
> https://bugzilla.kernel.org/show_bug.cgi?id=216911
> #regzbot title: mm: get_unmapped_area returns addresses below mmap_min_addr
> #regzbot ignore-activity
>
> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
> --
> Everything you wanna know about Linux kernel regression tracking:
> https://linux-regtracking.leemhuis.info/about/#tldr
> If I did something stupid, please tell me, as explained on that page.
* Linux kernel regression tracking (Thorsten Leemhuis) <[email protected]> [230111 05:54]:
> [resent with akpm's proper email address (either me or my mailer did
> something stupid; sorry for the noise)]
>
> On 11.01.23 11:46, Linux kernel regression tracking (Thorsten Leemhuis)
> wrote:
> > Hi, I noticed a regression report in bugzilla.kernel.org. As many
> > (most?) kernel developer don't keep an eye on it, I decided to forward
> > it by mail. Quoting from
> > https://bugzilla.kernel.org/show_bug.cgi?id=216911 :
> >
> >> Amanieu d'Antras 2023-01-11 02:10:02 UTC
> >>
> >> 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
> >
> > [those are all from the Maple Tree introduction series]
> >
> >> 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).
> >
> > See the ticket for more details.
Thanks Thorsten.
I'm sure this is my bug. I've not been careful enough around the lower
bound checking in the maple tree function, which has caused a return of
an invalid location for mmap.
I'll send out a patch shortly.
> >
> > BTW, let me use this mail to also add the report to the list of tracked
> > regressions to ensure it's doesn't fall through the cracks:
> >
> > #regzbot introduced: d4af56c5c7c6..3499a13168da
> > https://bugzilla.kernel.org/show_bug.cgi?id=216911
> > #regzbot title: mm: get_unmapped_area returns addresses below mmap_min_addr
> > #regzbot ignore-activity
Just a note that the fixes tag will be outside the above introduced
range. It will be 54a611b60590 ("Maple Tree: add new data structure")
I hope this doesn't cause issues with the bots.
Cheers,
Liam
On 11.01.23 20:22, Liam Howlett wrote:
> * Linux kernel regression tracking (Thorsten Leemhuis) <[email protected]> [230111 05:54]:
> [...]
> Thanks Thorsten.
yw
> [...]
> I'll send out a patch shortly.
Great, thx!
>>> BTW, let me use this mail to also add the report to the list of tracked
>>> regressions to ensure it's doesn't fall through the cracks:
>>>
>>> #regzbot introduced: d4af56c5c7c6..3499a13168da
>>> https://bugzilla.kernel.org/show_bug.cgi?id=216911
>>> #regzbot title: mm: get_unmapped_area returns addresses below mmap_min_addr
>>> #regzbot ignore-activity
>
> Just a note that the fixes tag will be outside the above introduced
> range. It will be 54a611b60590 ("Maple Tree: add new data structure")
>
> I hope this doesn't cause issues with the bots.
Not at all. Regzbot currently[1] only looks out for Link: tags to the
report; in this case both a link to the start of this thread or the
bugzilla ticket will automatically be associated with the report, which
will be automatically marked as resolved by regzbot once a patch with
such a Link: tag lands in mainline.
Ciao, Thorsten
[1] a lot of people forget to place those Link: tags, that's why I at
some point will likely change regzbot to also consider patches as a
related where both the Reported-by and the commit id (in case it's a
fully bisected regression) match a tracked report.