On 09.05.25 17:55, Lorenzo Stoakes wrote:
On Fri, May 09, 2025 at 05:30:32PM +0200, David Hildenbrand wrote:
Let's test some basic functionality using /dev/mem. These tests will
implicitly cover some PAT (Page Attribute Handling) handling on x86.
These tests will only run when /dev/mem access to the first two pages
in physical address space is possible and allowed; otherwise, the tests
are skipped.
On current x86-64 with PAT inside a VM, all tests pass:
TAP version 13
1..6
# Starting 6 tests from 1 test cases.
# RUN pfnmap.madvise_disallowed ...
# OK pfnmap.madvise_disallowed
ok 1 pfnmap.madvise_disallowed
# RUN pfnmap.munmap_split ...
# OK pfnmap.munmap_split
ok 2 pfnmap.munmap_split
# RUN pfnmap.mremap_fixed ...
# OK pfnmap.mremap_fixed
ok 3 pfnmap.mremap_fixed
# RUN pfnmap.mremap_shrink ...
# OK pfnmap.mremap_shrink
ok 4 pfnmap.mremap_shrink
# RUN pfnmap.mremap_expand ...
# OK pfnmap.mremap_expand
ok 5 pfnmap.mremap_expand
# RUN pfnmap.fork ...
# OK pfnmap.fork
ok 6 pfnmap.fork
# PASSED: 6 / 6 tests passed.
# Totals: pass:6 fail:0 xfail:0 xpass:0 skip:0 error:0
However, we are able to trigger:
[ 27.888251] x86/PAT: pfnmap:1790 freeing invalid memtype [mem
0x00000000-0x00000fff]
There are probably more things worth testing in the future, such as
MAP_PRIVATE handling. But this set of tests is sufficient to cover most of
the things we will rework regarding PAT handling.
Cc: Andrew Morton <a...@linux-foundation.org>
Cc: Shuah Khan <sh...@kernel.org>
Cc: Lorenzo Stoakes <lorenzo.stoa...@oracle.com>
Cc: Ingo Molnar <mi...@redhat.com>
Cc: Peter Xu <pet...@redhat.com>
Cc: Dev Jain <dev.j...@arm.com>
Signed-off-by: David Hildenbrand <da...@redhat.com>
Nice, big improvement!
Reviewed-by: Lorenzo Stoakes <lorenzo.stoa...@oracle.com>
Thanks! It was worth spending the time on using the harness.
The FIXTURE_TEARDOWN() stuff is really confusing. It's not actually
required to teardown most stuff (unless you create files in setup etc),
because all tests are executed in a fork'ed child, where fd's, mappings,
... will go away immediately afterwards during the exit().
I still implemented FIXTURE_TEARDOWN (like everybody else), because
maybe the manual teardown can find other issues not triggered during exit().
--
Cheers,
David / dhildenb
