linux-kernel - Re: [PATCH v2] selftests/mm: add simple VM_PFNMAP tests based on mmap'ing /dev/mem

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <56a3ce13-f8fb-4f9a-93ea-ff77d7b109b1@redhat.com>
Date: Mon, 12 May 2025 10:18:05 +0200
From: David Hildenbrand <david@...hat.com>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org,
 linux-kselftest@...r.kernel.org, Andrew Morton <akpm@...ux-foundation.org>,
 Shuah Khan <shuah@...nel.org>, Ingo Molnar <mingo@...hat.com>,
 Peter Xu <peterx@...hat.com>, Dev Jain <dev.jain@....com>
Subject: Re: [PATCH v2] selftests/mm: add simple VM_PFNMAP tests based on
 mmap'ing /dev/mem

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@...ux-foundation.org>
>> Cc: Shuah Khan <shuah@...nel.org>
>> Cc: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
>> Cc: Ingo Molnar <mingo@...hat.com>
>> Cc: Peter Xu <peterx@...hat.com>
>> Cc: Dev Jain <dev.jain@....com>
>> Signed-off-by: David Hildenbrand <david@...hat.com>
> 
> Nice, big improvement!
> 
> Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@...cle.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