Re: [PATCH] selftests/mm: pass filename as input param to VM_PFNMAP tests

[David Hildenbrand <david@redhat.com>]

On 31.07.25 22:10, Sudarsan Mahendran wrote:
> Enable these tests to be run on other pfnmap'ed memory like
> NVIDIA's EGM.
> 
> Add '--' as a separator to pass in file path. This allows
> passing of cmd line arguments to kselftest_harness.
> Use '/dev/mem' as default filename.
> 
> Existing test passes:
> 	pfnmap
> 	TAP version 13
> 	1..6
> 	# Starting 6 tests from 1 test cases.
> 	# PASSED: 6 / 6 tests passed.
> 	# Totals: pass:6 fail:0 xfail:0 xpass:0 skip:0 error:0
> 
> Pass params to kselftest_harness:
> 	pfnmap -r pfnmap:mremap_fixed
> 	TAP version 13
> 	1..1
> 	# Starting 1 tests from 1 test cases.
> 	#  RUN           pfnmap.mremap_fixed ...
> 	#            OK  pfnmap.mremap_fixed
> 	ok 1 pfnmap.mremap_fixed
> 	# PASSED: 1 / 1 tests passed.
> 	# Totals: pass:1 fail:0 xfail:0 xpass:0 skip:0 error:0
> 
> Pass random file name as input:
> 	pfnmap -- /dev/blah
> 	TAP version 13
> 	1..6
> 	# Starting 6 tests from 1 test cases.
> 	#  RUN           pfnmap.madvise_disallowed ...
> 	#      SKIP      Cannot open '/dev/blah'

Now, if you really just pass a random *actual file* that exists, the 
test case will not actually test what we want.

Unless you have a way to verify that you actually get a PFNMAP mapping, 
this extension is questionable. It will make the test report possibly 
wrong results when wrong files are provided.

I think we can test whether we get a PFNMAP mapping by looking at the 
flags in smaps output ("pf" in flags), so I would expect such a test to 
be done in pfnmap, and the test should FAIL if the file would not create 
a PFNMAP.


But more importantly, we rely on "/proc/iomem" to find a RAM target in 
/dev/mem. That doesn't make any sense with what you are doing here.

If we are not provided /dev/mem, you should probably try mapping offset 
0 of the file.

-- 
Cheers,

David / dhildenb