On Tue, 6 Jan 2026 at 15:34, David Hildenbrand (Red Hat) david@kernel.org wrote:
I don't recall all the details, but I think that we might end up holding the folio lock forever while the fuse user space daemon is supposed to fill the page with data; anybody trying to lock the folio would similarly deadlock.
Right.
Maybe only compaction/migration is affected by that, hard to tell.
Can't imagine anything beyond actual I/O and folio logistics (reclaim/compaction) that would want to touch the page lock.
I/O has the right to wait forever on the folio if the server is stuck, that doesn't count as a deadlock.
The logistics functions are careful to use folio_trylock(), but they could give a hint to fuse via a callback that they'd like to have this particular folio. In that case fuse would be free to cancel the read and let the whole thing be retried with a new folio.
What we really need is a failing test case, the rest should be easy ;-)
I'm not sure about temp buffers. During early discussions there were ideas about canceling writeback and instead marking the folio dirty again. I assume there is a non-trivial solution space left unexplored for now.
That might work combined with the suggested callback to fix the compaction issue.
But I don't see how it would be a generic replacement for the tmp page code.
Thanks, Miklos