From: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
To: "David Hildenbrand (Red Hat)" <david@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
"Liam R . Howlett" <Liam.Howlett@oracle.com>,
Vlastimil Babka <vbabka@suse.cz>, Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
linux-kselftest@vger.kernel.org, Mark Brown <broonie@kernel.org>
Subject: Re: [PATCH] selftests/mm: remove virtual_address_range test
Date: Mon, 19 Jan 2026 11:16:29 +0000 [thread overview]
Message-ID: <7b4c877e-3ad9-42b3-91bd-e65390f9a343@lucifer.local> (raw)
In-Reply-To: <a6479b82-a68c-49f5-8631-b3f536059352@kernel.org>
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
prev parent reply other threads:[~2026-01-19 11:16 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-16 13:20 Lorenzo Stoakes
2026-01-17 1:21 ` SeongJae Park
2026-01-18 7:55 ` Dev Jain
2026-01-18 12:58 ` Lorenzo Stoakes
2026-01-19 6:21 ` Dev Jain
2026-01-19 8:59 ` Lorenzo Stoakes
2026-01-19 9:06 ` Dev Jain
2026-01-19 9:13 ` Lorenzo Stoakes
2026-01-19 11:11 ` Lorenzo Stoakes
2026-01-20 5:29 ` Dev Jain
2026-01-20 8:43 ` Lorenzo Stoakes
2026-01-20 10:20 ` Dev Jain
2026-01-19 10:39 ` David Hildenbrand (Red Hat)
2026-01-19 11:06 ` Lorenzo Stoakes
2026-01-19 11:11 ` David Hildenbrand (Red Hat)
2026-01-19 11:16 ` Lorenzo Stoakes [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7b4c877e-3ad9-42b3-91bd-e65390f9a343@lucifer.local \
--to=lorenzo.stoakes@oracle.com \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=broonie@kernel.org \
--cc=david@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=rppt@kernel.org \
--cc=surenb@google.com \
--cc=vbabka@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox