Re: [PATCH] 9p/virtio: restrict page pinning to user_backed_iter() iovec

[Christian Schoenebeck <linux_oss@crudebyte.com>]

On Tuesday, 9 December 2025 22:04:23 CET Dominique Martinet via B4 Relay 
wrote:
> From: Dominique Martinet <asmadeus@codewreck.org>
> 
> When doing a loop mount of a filesystem over 9p, read requests can come
> from unexpected places and blow up as reported by Chris Arges with this
> reproducer:
> ```
> dd if=/dev/zero of=./xfs.img bs=1M count=300
> yes | mkfs.xfs -b size=8192 ./xfs.img
> rm -rf ./mount && mkdir -p ./mount
> mount -o loop ./xfs.img ./mount
> ```
> 
> The problem is that iov_iter_get_pages_alloc2() apparently cannot be
> called on folios (as illustrated by the backtrace below), so limit what
> iov we can pin from !iov_iter_is_kvec() to user_backed_iter()
[...] 
> diff --git a/net/9p/trans_virtio.c b/net/9p/trans_virtio.c
> index
> 10c2dd48643818907f4370243eb971fceba4d40b..f7ee1f864b03a59568510eb0dd3496bd0
> 5b3b8d6 100644 --- a/net/9p/trans_virtio.c
> +++ b/net/9p/trans_virtio.c
> @@ -318,7 +318,7 @@ static int p9_get_mapped_pages(struct virtio_chan *chan,
> if (!iov_iter_count(data))
>  		return 0;
> 
> -	if (!iov_iter_is_kvec(data)) {
> +	if (user_backed_iter(data)) {
>  		int n;
>  		/*
>  		 * We allow only p9_max_pages pinned. We wait for the
> 
> ---
> base-commit: 3e281113f871d7f9c69ca55a4d806a72180b7e8a
> change-id: 20251210-virtio_trans_iter-5973892db2e3

Something's seriously messed up with 9p cache right now. With today's git 
master I do get data corruption in any 9p cache mode, including cache=mmap, 
only cache=none behaves clean.

With this patch applied though it gets even worse as I can't even boot due to 
immediate 9p data corruption. Could be coincidence, as I get corruption 
without this patch in any cache mode as well, but at least I have to try much 
harder to trigger it.

Currently busy with other stuff, so could be a while before being able to 
identify the cause.

/Christian