On 11/20/25 19:42, Joanne Koong wrote:
AS_WRITEBACK_MAY_DEADLOCK_ON_RECLAIM was added to avoid waiting on writeback during reclaim for inodes belonging to filesystems where a) waiting on writeback in reclaim may lead to a deadlock or b) a writeback request may never complete due to the nature of the filesystem (unrelated to reclaim)
Rename AS_WRITEBACK_MAY_DEADLOCK_ON_RECLAIM to the more generic AS_WRITEBACK_MAY_HANG to reflect mappings where writeback may hang where the cause could be unrelated to reclaim.
This allows us to later use AS_WRITEBACK_MAY_HANG to mitigate other scenarios such as possible hangs when sync waits on writeback.
Hmm, there is a difference whether writeback may hang or whether writeback may deadlock.
In particular, isn't it the case that writeback on any filesystem might effectively hang forever on I/O errors etc?
Is this going back to the previous flag semantics before we decided on AS_WRITEBACK_MAY_DEADLOCK_ON_RECLAIM? (I'd have to look at the previous discussions, but "writeback may take an indefinite amount" in patch #2 pretty much looks like what I remember there)