On Mon, Jan 19, 2026 at 12:11:39PM +0100, David Hildenbrand (Red Hat) wrote: > On 1/19/26 12:06, Lorenzo Stoakes wrote: > > On Mon, Jan 19, 2026 at 11:39:51AM +0100, David Hildenbrand (Red Hat) wrote: > > > On > > > > > > $ uname -r > > > 6.18.4-200.fc43.x86_64 > > > > > > I am getting > > > > > > $ ./va_high_addr_switch > > > mmap(addr_switch_hint - pagesize, pagesize): 0x7fe7de6d7000 - OK > > > mmap(addr_switch_hint - pagesize, (2 * pagesize)): 0x7fe7de6d6000 - OK > > > mmap(addr_switch_hint, pagesize): 0x7fe7de6d7000 - OK > > > mmap(addr_switch_hint, 2 * pagesize, MAP_FIXED): 0xffffffffffffffff - > > > FAILED > > > mmap(NULL): 0x7fe7de6d5000 - OK > > > mmap(low_addr): 0x40000000 - OK > > > mmap(high_addr): 0x7fe7de6d5000 - OK > > > mmap(high_addr) again: 0x7fe7de6d3000 - OK > > > mmap(high_addr, MAP_FIXED): 0xffffffffffffffff - FAILED > > > mmap(-1): 0x7fe7de6d1000 - OK > > > mmap(-1) again: 0x7fe7de6cf000 - OK > > > mmap(addr_switch_hint - pagesize, pagesize): 0x7fe7de6d0000 - OK > > > mmap(addr_switch_hint - pagesize, 2 * pagesize): 0x7fe7de6cf000 - OK > > > mmap(addr_switch_hint - pagesize/2 , 2 * pagesize): 0x7fe7de6cd000 - OK > > > mmap(addr_switch_hint, pagesize): 0x7fe7de6cc000 - OK > > > mmap(addr_switch_hint, 2 * pagesize, MAP_FIXED): 0xffffffffffffffff - > > > FAILED > > > > > > > > > Are these the same issues you see? > > > > No, that's entirely separate bug it seems :) > > > > Oh, lol, I ran the wrong test.
:)) but found another bug... > > Yes, on Fedora config I just get > > $ ./virtual_address_range > TAP version 13 > 1..1 > ok 1 # SKIP prctl(PR_SET_VMA_ANON_NAME) not supported > # 1 skipped test(s) detected. Consider enabling relevant config options to > improve coverage. > # Totals: pass:0 fail:0 xfail:0 xpass:0 skip:1 error:0 Yeah and the test runners seem to be the same, so this test has just _not been running_ for a long while. Then if you configure a kernel that _does_ support this, it fails with a test assertion. I tried to dig in and it seemed that the logic just got confused rather than it being a legit failure as it's making odd impl detail asserts about lengths of gaps between VMA regions... > > > > Seems to work locally for me on 6.18.3, and also in VM with tip mm-unstable, > > strange. > > Maybe a hardware thing (notebook not supporting 5 level page tables, maybe?) Yeah and that's something that should probably be addressed... you'd think it'd pass anyway? > > > > > The issue here is with virtual_address_space.c which seems to just to be > > generally broken, I couldn't even bisect to a working one, and I really did > > try. > > > > Actually hang on, isn't va_high_addr_space already then testing what > > virtual_address_space should be testing anyway if it were sensible?? > > > > That suggests then that just removing virtual_address_space without > > replacement (since this already exists) is the right way (...!) > > I cannot really judge, I would have to decipher the details of the tests ... Yup, in any case removal of a test that is fundamentally broken to the point of not being able to bisect it, that doesn't mmake any sense, that risks timeout due to it taking so long doing something crazy (it tries to map across ALL of the VA address space), that relies on implementation details of the kernel/libc (i.e. how the space is laid out in the first place), etc. makes sense. It is just not useful, and needs to be replaced with something that is. If we want to unit test get_unmapped_area(), then we should unit test get_unmapped_area() in isolation. It's actively broken and harmful to keep a broken test case around. A replacement that works can be added later. > > -- > Cheers > > David Thanks, Lorenzo
