Messages in this thread |  | | Date | Fri, 5 Dec 2025 22:48:55 +0900 | | From | Dominique Martinet <> | | Subject | Re: kernel BUG when mounting large block xfs backed by 9p (folio ref count bug) |
| |
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
|  |