Maple tree MAP_32BIT issue

["Edgecombe, Rick P" <rick.p.edgecombe@intel.com>]

Hi,

Some of the x86 selftests (ex: sysret_ss_attrs.c) that use MAP_32BIT
break after commit 58c5d0d6d522 (in v6.3). The MAP_32BIT mmap() acts as
if there is no suitable gap when there should be one.

Debugging a little:
MAP_32BIT starts with a bottom up search with a relatively low
high_limit. In unmapped_area(), mas_empty_area() finds a gap within the
limits, then looks for the next VMA with mas_next() to check
vm_start_gap(). In the debugged case, this is outside the limit (up in
the 64 bit address space), but all seems normal so far. Then it calls
mas_prev() trying to check vm_end_gap() on the VMA below the gap found.

This is where it starts to not make sense to me. The VMA returned by
mas_prev() is also above the high_limit. It's as if the earlier
mas_next() skipped over the actual next VMA from the gap, to the second
next one.

In the case debugged, the mas_prev() VMA is also way above the 32 bit
address space. So it finds (vm_end_gap(tmp) > gap) to be true and sets
low_limit to vm_end_gap(tmp) and retries. But then low_limit (up in the
64 bit address space) is above high_limit (in the 32 bit address
space), and unmapped_area() fails with -ENOMEM.

I looked at fixing it, but I'm not sure of the expected behavior of
mas_prev/mas_next(). So instead I'm just reporting it for now, until I
can look at it with a fresh head.

Not every system failed with the same tests. For example,
fsgsbase_restorer.c failed on some systems but not others. So
presumably some other factors are at work. Please let me know if I can
help with any extra testing or debugging.

Rick