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