Re: [PATCH RFC v4 08/12] selftests/mm: cover /proc/pid/mem access to VM_PFNMAP memory

[John Hubbard <jhubbard@nvidia.com>]

On 7/24/26 3:29 PM, Rik van Riel wrote:
> Reading a VM_PFNMAP mapping through /proc/pid/mem exercises
> __access_remote_vm() two ways: a COWed page has a struct page and is
> returned by get_user_page_vma(), while a raw PFN has none and is reached
> through vma->vm_ops->access().
> 
> Add two tests to pfnmap.c, both reading VM_PFNMAP memory through
> /proc/self/mem.
> 
> procmem_cow_read maps the file MAP_PRIVATE and writable, writes to COW a
> page, then reads it back. Without the struct-page path in
> get_user_page_vma() this read is short: the access falls back to
> generic_access_phys(), which ioremaps the PFN, and ioremap of a COWed RAM
> page is rejected.

This is architecture-dependent. RISC-V uses generic_ioremap_prot(),
which does not reject RAM, so the old ->access() path can read the COWed
page and this test can pass without exercising get_user_page_vma().

The raw test has the same observability problem: checking only the byte
count cannot distinguish ->access() from an erroneous GUP result for a
PFNMAP of normal RAM. 

Should we instead use a deterministic PFNMAP test provider
whose mapped page contains one pattern and whose ->access() callback
returns another? The COW test could require the anonymous data and the
raw test could require the ->access() pattern. That would also avoid
reading arbitrary MMIO and skipping the raw case in the default run.


> 
> procmem_pfn_read reads a raw PFN back through ->access(). ioremap rejects
> RAM, so it runs only for genuine device memory and is skipped for the
> default /dev/mem System RAM target.
> 
> Assisted-by: Claude:claude-opus-4.8
> Signed-off-by: Rik van Riel <riel@surriel.com>
> ---
>  tools/testing/selftests/mm/pfnmap.c | 66 +++++++++++++++++++++++++++++
>  1 file changed, 66 insertions(+)
> 
> diff --git a/tools/testing/selftests/mm/pfnmap.c b/tools/testing/selftests/mm/pfnmap.c
> index 4f550822385a..6ff5d1029517 100644
> --- a/tools/testing/selftests/mm/pfnmap.c
> +++ b/tools/testing/selftests/mm/pfnmap.c
> @@ -31,6 +31,7 @@ static sigjmp_buf sigjmp_buf_env;
>  static char *file = "/dev/mem";
>  static off_t file_offset;
>  static int fd;
> +static int target_is_ram;
>  
>  static void signal_handler(int sig)
>  {
> @@ -113,6 +114,7 @@ static void pfnmap_init(void)
>  		if (err)
>  			ksft_exit_skip("Cannot find ram target in '/proc/iomem': %s\n",
>  				       strerror(-err));
> +		target_is_ram = 1;
>  	} else {
>  		file_offset = 0;
>  	}
> @@ -271,6 +273,70 @@ TEST_F(pfnmap, fork)
>  	ASSERT_EQ(ret, 0);
>  }
>  
> +TEST_F(pfnmap, procmem_cow_read)
> +{
> +	char *priv, *buf;
> +	ssize_t rc;
> +	int mem_fd;
> +
> +	/*
> +	 * A COWed page in a VM_PFNMAP mapping has a struct page, so reading it
> +	 * through /proc/self/mem -- __access_remote_vm() -> get_user_page_vma()
> +	 * -- returns it directly, instead of routing to vma->vm_ops->access(),
> +	 * which ioremaps the PFN and cannot reach a COWed RAM page.
> +	 *
> +	 * Map the file MAP_PRIVATE and writable, write to COW a page into anon
> +	 * memory, then read the page back through /proc/self/mem.
> +	 */
> +	self->size2 = self->pagesize;
> +	self->addr2 = mmap(NULL, self->size2, PROT_READ | PROT_WRITE,
> +			   MAP_PRIVATE, fd, file_offset);
> +	if (self->addr2 == MAP_FAILED)
> +		SKIP(return, "Cannot create a writable private pfnmap mapping");
> +	priv = self->addr2;
> +
> +	/* COW the page and stamp known bytes into the anon copy. */
> +	priv[0] = 0x42;
> +	priv[self->pagesize - 1] = 0x24;
> +
> +	buf = malloc(self->pagesize);
> +	ASSERT_NE(buf, NULL);
> +
> +	mem_fd = open("/proc/self/mem", O_RDONLY);
> +	ASSERT_GE(mem_fd, 0);
> +	rc = pread(mem_fd, buf, self->pagesize, (off_t)(uintptr_t)priv);
> +	close(mem_fd);
> +
> +	ASSERT_EQ(rc, (ssize_t)self->pagesize);
> +	EXPECT_EQ(buf[0], 0x42);
> +	EXPECT_EQ(buf[self->pagesize - 1], 0x24);
> +
> +	free(buf);
> +}
> +
> +TEST_F(pfnmap, procmem_pfn_read)
> +{
> +	char buf[64];
> +	ssize_t rc;
> +	int mem_fd;
> +
> +	/*
> +	 * A raw PFN of a VM_IO/VM_PFNMAP mapping has no struct page, so

That is not the VM_PFNMAP invariant. A raw mapping is treated as special
even when its PFN has a valid struct page. Please describe this as GUP
not returning a page for the raw mapping, here and in patches 5 and 6.

The new pread() offsets also need 64-bit off_t. On a 32-bit ABI, a
mapping at or above 2 GiB converts to a negative off_t, and pread64()
rejects it before /proc/self/mem sees the offset.



thanks,
-- 
John Hubbard