Thanks for the review! I've sent a follow up v2 patch.
On Fri, Aug 1, 2025 at 12:15 AM David Hildenbrand david@redhat.com wrote:
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