On Fri, 24 Jan 2025 at 13:29, David Hildenbrand <david@xxxxxxxxxx> wrote: > Yeah, that was one of my initial questions as well: could one > "transparently" (to user space) handle canceling writeback and simply > re-dirty the page. 1) WRITE request is not yet dequeued by userspace: the writeback can be cancelled 2/a) WRITE request is dequeued (copied) to userspace: the page can be reused, but the writeback isn't yet complete. Calling folio_end_writeback() is lying in the same sense that it's lying with temp pages. 2/b) WRITE request is dequeued (spliced) to userspace: the page is referenced indefinitely (could even be after the writeback completes). Temp page could be allocated at splice time, which means performance will be no better than with current temp page writeback, but at least it will be less complex. 3) WRITE request is currently being copied to userspace: this should normally be short, but userspace can be nasty and have the buffer be an mmap of another fuse file, and make the copy hang in the middle by triggering a page fault. The request cannot be cancelled at this point. In such a case the "echo 1 > /sys/fs/fuse/connections/##/abort" mechanism or the upcoming server timeout can be used to shutdown the filesystem. So this is definitely more complicated than I'd like. Thanks, Miklos
