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

[Dominique Martinet <asmadeus@codewreck.org>]

Christian Schoenebeck wrote on Fri, Dec 05, 2025 at 02:36:41PM +0100:
> Haven't checked yet, but shouldn't it be like this?
> 
> diff --git a/net/9p/trans_virtio.c b/net/9p/trans_virtio.c
> index 0b8086f58ad5..5ff4bfe25a3e 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 (iov_iter_is_iovec(data)) {

Hmm, __iov_iter_get_pages_alloc() is supposed to handle any of these:
user_backed_iter() (iter_is_ubuf() || iter_is_iovec()),
iov_iter_is_bvec(),
iov_iter_is_folioq(),
iov_iter_is_xarray()

so it would EFAULT on stuff like is_discard() and is_kvec(), but in our
case (folio) it also depends on what backs the folio, and just the type
of the iov isn't enough to tell

Your patch will appear to work (folioq path won't go there so the page
won't be pinned), but I'm not sure just being a folio is enough of a
guarantee here? for example is a folio coming from page cache
(e.g. readahead) guaranteed to be stable while it is being read? Can
something (try to) kill that thread while the IO is in progress and
reclaim the memory?

-- 
Dominique Martinet | Asmadeus