On Fri, Dec 20, 2024 at 03:49:39PM +0100, David Hildenbrand wrote: > > > I'm wondering if there would be a way to just "cancel" the writeback and > > > mark the folio dirty again. That way it could be migrated, but not > > > reclaimed. At least we could avoid the whole AS_WRITEBACK_INDETERMINATE > > > thing. > > > > > > > That is what I basically meant with short timeouts. Obviously it is not > > that simple to cancel the request and to retry - it would add in quite > > some complexity, if all the issues that arise can be solved at all. > > At least it would keep that out of core-mm. > > AS_WRITEBACK_INDETERMINATE really has weird smell to it ... we should try to > improve such scenarios, not acknowledge and integrate them, then work around > using timeouts that must be manually configured, and ca likely no be default > enabled because it could hurt reasonable use cases :( Just to be clear AS_WRITEBACK_INDETERMINATE is being used in two core-mm parts. First is reclaim and second is compaction/migration. For reclaim, it is a must have as explained by Jingbo in [1] i.e. due to potential self deadlock by fuse server. If I understand you correctly, the main concern you have is its usage in the second case. The reason for adding AS_WRITEBACK_INDETERMINATE in the second case was to avoid untrusted fuse server causing pain to unrelated jobs on the machine (fuse folks please correct me if I am wrong here). Now we are discussing how to better handle that scenario. I just wanted to point out that irrespective of that discussion, the reclaim will have handle the potential recursive deadlock and thus will be using AS_WRITEBACK_INDETERMINATE or something similar. [1] https://lore.kernel.org/all/d48ae58e-500f-4ef1-bc6f-a41a8f5b94bf@xxxxxxxxxxxxxxxxx/
