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
