On 12/19/24 18:55, Joanne Koong wrote: > On Thu, Dec 19, 2024 at 9:26 AM David Hildenbrand <david@xxxxxxxxxx> wrote: >> >> On 19.12.24 18:14, Shakeel Butt wrote: >>> 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? >> > > This scenario can already happen with temp pages. An untrusted > malicious fuse server may allocate and dirty a lot of fuse folios > within its dirty/memcg limits and never clear writeback on any of them > and tie up system resources. This certainly isn't the common case, but > it is a possibility. However, request timeouts can be set by the > system admin [1] to protect against malicious/buggy fuse servers that > try to do this. If the request isn't replied to by a certain amount of > time, then the connection will be aborted and writeback state and > other resources will be cleared/freed. > I think what Zi points out that that is a current implementation issue and these temp pages should be in a continues range. Obviously better to avoid a tmp copy at all. Thanks, Bernd
