Re: kernel BUG when mounting large block xfs backed by 9p (folio ref count bug)

[Christian Schoenebeck <linux_oss@crudebyte.com>]

On Sunday, 7 December 2025 14:49:31 CET Dominique Martinet wrote:
> Chris,
> 
> I'm not sure why but I can't reproduce with your .config either :/
> If you can still reproduce this reliably, could you try with the
> following diff applied (which is basically the same as what Christian
> suggested a couple of days ago with also ubuf, whatever that is)
> ------------
> diff --git a/net/9p/trans_virtio.c b/net/9p/trans_virtio.c
> index 10c2dd486438..f7ee1f864b03 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
> -----------

Right, that's clearly better than what I suggested. Feel free to add:

Reviewed-by: Christian Schoenebeck <linux_oss@crudebyte.com>

Honestly I think those iov_iter functions and/or iter_type enums deserve some 
API doc comments. At least I don't find it self explanatory what the 
differences between the individual iterator types are.

/Christian

> Willy,
> 
> Matthew Wilcox wrote on Sun, Dec 07, 2025 at 07:18:02AM +0000:
> > In readahead, we allocate a folio, lock it and add it to the page cache.
> > We then submit it to the filesystem for read.  It cannot be truncated
> > from the page cache until the filesystem unlocks it (generally by calling
> > folio_end_read() but some filesystems explicitly call folio_unlock()
> > instead).  So you don't need to take an extra reference to it.
> 
> Thanks.
> 
> My main problem with this all is that trans_virtio adds the buffers to
> the virtio virtqueue but does nothing to take it off if
> wait_event_killable() in virtio_request() gets killed, but looking at it
> even in the code path that gets a ref the code will happily drop the ref
> even before the flush is over so I guess there's no reason to actively
> try to pin kernel pages...
> 
> I'd sleep better if there was a way to remove (detach?) the buffer from
> the virtqueue but I can't see how to do that without breaking something
> else, so I guess we'll have to live with that behavior unless someone
> knows better.