Re: [PATCH] selftests/mm: remove virtual_address_range test

["David Hildenbrand (Red Hat)" <david@kernel.org>]

On 1/16/26 14:20, Lorenzo Stoakes wrote:
> This self test is asserting internal implementation details and is highly
> vulnerable to internal kernel changes as a result.
> 
> It is currently failing locally from at least v6.17, and it seems that it
> may have been failing for longer in many configurations/hardware as it
> skips if e.g. CONFIG_ANON_VMA_NAME is not specified.
> 
> With these skips and the fact that run_vmtests.sh won't run the tests in
> certain configurations it is likely we have simply missed this test being
> broken in CI for a long while.
> 
> I have tried multiple versions of these tests and am unable to find a
> working bisect as previous versions of the test fail also.
> 
> The tests are essentially mmap()'ing a series of mappings with no hint and
> asserting what the get_unmapped_area*() functions will come up with, with
> seemingly few checks for what other mappings may already be in place.
> 
> It then appears to be mmap()'ing with a hint, and making a series of
> similar assertions about the internal implementation details of the hinting
> logic.
> 
> Commit 0ef3783d7558 ("selftests/mm: add support to test 4PB VA on PPC64"),
> commit 3bd6137220bb ("selftests/mm: virtual_address_range: avoid reading
> from VM_IO mappings"), and especially commit a005145b9c96 ("selftests/mm:
> virtual_address_range: mmap() without PROT_WRITE") are good examples of the
> whack-a-mole nature of maintaining this test.
> 
> The last commit there being particularly pertinent as it was accounting for
> an internal implementation detail change that really should have no bearing
> on self-tests, that is commit e93d2521b27f ("x86/vdso: Split virtual clock
> pages into dedicated mapping").
> 
> The purpose of the mm self-tests are to assert attributes about the API
> exposed to users, and to ensure that expectations are met.
> 
> This test is emphatically not doing this, rather making a series of
> assumptions about internal implementation details and asserting them.
> 
> It therefore, sadly, seems that the best course is to remove this test
> altogether.
> 
> Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>

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?

-- 
Cheers

David