Re: 9p read corruption of mmaped content (Was: [PATCH] 9p/virtio: restrict page pinning to user_backed_iter() iovec)

[Dominique Martinet <asmadeus@codewreck.org>]

Dominique Martinet wrote on Fri, Dec 19, 2025 at 01:09:26PM +0900:
> - I took a dump of dmesg (with debug=65535) and tracepoints (netfs, 9p),
> and it looks like the mmaped file IO is mostly correct? -- a TREAD is
> issued with the correct size, I'm seeing the data is collected... and..
> what is that ZERO SUBMT with the same size? Could it be related?
> David, could you please have a look?

So answering myself on that ZERO submit now I've looked up the
tracepoint definition, s=%x is the start offset and the following item
is the length so [0-5fb2[ was "downloaded from the server" and
[5fb2-6000[ was "filled with zero", and there's nothing wrong here...

Both are triggered straight from the page fault so that answers my last
question as well:

clang     691 [000] 18146.476058: netfs:netfs_sreq: R=0003306d[1] DOWN TERM  f=192 s=0 5fb2/5fb2 s=5 e=0
        ffffffff81601197 __traceiter_netfs_sreq+0x37 ([kernel.kallsyms])
        ffffffff8160625a netfs_read_subreq_terminated+0x10a ([kernel.kallsyms])
        ffffffff817fcbc6 v9fs_issue_read+0x86 ([kernel.kallsyms])
        ffffffff815fd86b netfs_read_to_pagecache+0x18b ([kernel.kallsyms])
        ffffffff815fdc62 netfs_readahead+0x152 ([kernel.kallsyms])
        ffffffff814b9c2a read_pages+0x4a ([kernel.kallsyms])
        ffffffff814b9f20 page_cache_ra_unbounded+0x190 ([kernel.kallsyms])
        ffffffff814ba677 page_cache_ra_order+0x387 ([kernel.kallsyms])
        ffffffff814ae2a9 filemap_fault+0x5c9 ([kernel.kallsyms])
        ffffffff814ee518 __do_fault+0x38 ([kernel.kallsyms])
        ffffffff814f83a5 __handle_mm_fault+0xbb5 ([kernel.kallsyms])
        ffffffff814f9509 handle_mm_fault+0x99 ([kernel.kallsyms])
        ffffffff812a6e2f do_user_addr_fault+0x1ef ([kernel.kallsyms])
        ffffffff81ceb097 exc_page_fault+0x67 ([kernel.kallsyms])
        ffffffff81000bb7 asm_exc_page_fault+0x27 ([kernel.kallsyms])
            7f776ed86c23 clang::SrcMgr::ContentCache::getInvalidBOM(llvm::StringRef)+0x13 (/usr/lib/x86_64-linux-gnu/li

Which leaves me absolutely clueless at where to look next, I assume the
data is populated cleanly but by the time later pages are read by clang
the content changed or something like that?
I'll try harder to create a synthetic/more deterministic reproducer for
now...

Any ideas welcome...!
-- 
Dominique Martinet | Asmadeus