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. Thanks, Joanne [1] https://lore.kernel.org/linux-fsdevel/20241218222630.99920-1-joannelkoong@xxxxxxxxx/T/#t > Yes, for example causing harm on a shared host (containers, ...). > > If it cannot happen, we should make it very clear in documentation and > patch descriptions that it can only cause harm with privileged user > space, and that this harm can make things like CMA allocations, memory > onplug, ... fail, which is rather bad and against concepts like > ZONE_MOVABLE/MIGRATE_CMA. > > Although I wonder what would happen if the privileged user space daemon > crashes (e.g., OOM killer?) and simply no longer replies to any messages. > > -- > Cheers, > > David / dhildenb >
