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?
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
