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

[Matthew Wilcox <willy@infradead.org>]

On Fri, Dec 05, 2025 at 10:48:55PM +0900, Dominique Martinet wrote:
> 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?

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.