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 <[email protected]> > --- > 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
