Re: [PATCH v6 4/5] mm/migrate: skip migrating folios under writeback with AS_WRITEBACK_INDETERMINATE mappings

[Joanne Koong <joannelkoong@gmail.com>]

On Thu, Dec 19, 2024 at 9:26 AM David Hildenbrand <david@redhat.com> 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@gmail.com/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
>