linux-kernel - Re: [PATCH] selftests/mm: remove virtual_address

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <7b4c877e-3ad9-42b3-91bd-e65390f9a343@lucifer.local>
Date: Mon, 19 Jan 2026 11:16:29 +0000
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: "David Hildenbrand (Red Hat)" <david@...nel.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
        "Liam R . Howlett" <Liam.Howlett@...cle.com>,
        Vlastimil Babka <vbabka@...e.cz>, Mike Rapoport <rppt@...nel.org>,
        Suren Baghdasaryan <surenb@...gle.com>, Michal Hocko <mhocko@...e.com>,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        linux-kselftest@...r.kernel.org, Mark Brown <broonie@...nel.org>
Subject: Re: [PATCH] selftests/mm: remove virtual_address_range test

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