On Thu, Dec 19, 2024 at 05:41:36PM +0100, David Hildenbrand wrote: > On 19.12.24 17:40, Shakeel Butt wrote: > > On Thu, Dec 19, 2024 at 05:29:08PM +0100, David Hildenbrand wrote: > > [...] > > > > > > > > If you check the code just above this patch, this > > > > mapping_writeback_indeterminate() check only happen for pages under > > > > writeback which is a temp state. Anyways, fuse folios should not be > > > > unmovable for their lifetime but only while under writeback which is > > > > same for all fs. > > > > > > But there, writeback is expected to be a temporary thing, not possibly: > > > "AS_WRITEBACK_INDETERMINATE", that is a BIG difference. > > > > > > I'll have to NACK anything that violates ZONE_MOVABLE / ALLOC_CMA > > > guarantees, and unfortunately, it sounds like this is the case here, unless > > > I am missing something important. > > > > > > > It might just be the name "AS_WRITEBACK_INDETERMINATE" is causing > > the confusion. The writeback state is not indefinite. A proper fuse fs, > > like anyother fs, should handle writeback pages appropriately. These > > additional checks and skips are for (I think) untrusted fuse servers. > > Can unprivileged user space provoke this case? Let's ask Joanne and other fuse folks about the above question. Let's say unprivileged user space can start a untrusted fuse server, mount fuse, allocate and dirty a lot of fuse folios (within its dirty and memcg limits) and trigger the writeback. To cause pain (through fragmentation), it is not clearing the writeback state. Is this the scenario you are envisioning?
