linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
To: David Hildenbrand <david@redhat.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-kselftest@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Shuah Khan <shuah@kernel.org>, Ingo Molnar <mingo@redhat.com>,
	Peter Xu <peterx@redhat.com>, Dev Jain <dev.jain@arm.com>
Subject: Re: [PATCH v2] selftests/mm: add simple VM_PFNMAP tests based on mmap'ing /dev/mem
Date: Mon, 12 May 2025 12:52:07 +0100	[thread overview]
Message-ID: <eff9451a-ab92-4686-97dd-a53d10da6bc7@lucifer.local> (raw)
In-Reply-To: <56a3ce13-f8fb-4f9a-93ea-ff77d7b109b1@redhat.com>

On Mon, May 12, 2025 at 10:18:05AM +0200, David Hildenbrand wrote:
> 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 <akpm@linux-foundation.org>
> > > Cc: Shuah Khan <shuah@kernel.org>
> > > Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
> > > Cc: Ingo Molnar <mingo@redhat.com>
> > > Cc: Peter Xu <peterx@redhat.com>
> > > Cc: Dev Jain <dev.jain@arm.com>
> > > Signed-off-by: David Hildenbrand <david@redhat.com>
> >
> > Nice, big improvement!
> >
> > Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@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().

Yeah, it's maybe not always necessary, but stil handy, and at least allows for
strict cleanup/separation between tests.

And having things structured this way makes life much easier in many other
regards, as you have one place for it, you don't have to manually fiddle with
test counts etc. etc.

Overall I think it's a big win :)

>
> I still implemented FIXTURE_TEARDOWN (like everybody else), because maybe
> the manual teardown can find other issues not triggered during exit().

Ack!

>
> --
> Cheers,
>
> David / dhildenb
>

Cheers, Lorenzo


  reply	other threads:[~2025-05-12 11:52 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-09 15:30 David Hildenbrand
2025-05-09 15:55 ` Lorenzo Stoakes
2025-05-12  8:18   ` David Hildenbrand
2025-05-12 11:52     ` Lorenzo Stoakes [this message]
2025-05-28 10:34 ` Ryan Roberts
2025-05-28 10:44   ` David Hildenbrand
2025-05-28 10:48     ` David Hildenbrand
2025-05-28 10:53       ` Ryan Roberts
2025-05-28 11:03         ` David Hildenbrand
2025-05-28 12:40         ` David Hildenbrand
2025-05-28 13:44           ` Ryan Roberts
2025-05-28 18:23             ` Aishwarya
2025-05-28 19:47               ` David Hildenbrand

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=eff9451a-ab92-4686-97dd-a53d10da6bc7@lucifer.local \
    --to=lorenzo.stoakes@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=david@redhat.com \
    --cc=dev.jain@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mingo@redhat.com \
    --cc=peterx@redhat.com \
    --cc=shuah@kernel.org \
    /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