Message-ID: <e001f009-0aeb-4a59-950e-3e5ed1c55751@redhat.com>
Date: Tue, 23 Apr 2024 23:02:40 +0200
From: David Hildenbrand <david@...hat.com>
To: Shivansh Vij <shivanshvij@...look.com>,
 Ryan Roberts <ryan.roberts@....com>, Mike Rapoport <rppt@...ux.ibm.com>
Cc: Catalin Marinas <catalin.marinas@....com>, Will Deacon <will@...nel.org>,
 Andrew Morton <akpm@...ux-foundation.org>, Shuah Khan <shuah@...nel.org>,
 Joey Gouly <joey.gouly@....com>, Ard Biesheuvel <ardb@...nel.org>,
 Mark Rutland <mark.rutland@....com>,
 Anshuman Khandual <anshuman.khandual@....com>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "linux-arm-kernel@...ts.infradead.org"
 <linux-arm-kernel@...ts.infradead.org>,
 "linux-kselftest@...r.kernel.org" <linux-kselftest@...r.kernel.org>
Subject: Re: [PATCH v1 0/5] arm64/mm: uffd write-protect and soft-dirty
 tracking

>>
>> Shivansh, do you speak for CRIU? Are you able to comment on whether CRIU
>> supports checkpointing an app that uses uffd?
> 
> I do not speak for CRIU - I'm just a user (and hopefully a future contributor), but not a maintainer or owner. I can however comment on whether CRIU supports checkpointing an app that uses UFFD - it doesn't. Looking through both the implementation of CRIU (specifically how they restore memory [1]), and at recently filed Github issues [2], it's pretty clear that CRIU doesn't support processes using UFFD - that they do not currently have plans to [3].

Thanks for all these pointers!

> 
> [1] https://github.com/checkpoint-restore/criu/blob/criu-2.x-stable/criu/mem.c#L683
> [2] https://github.com/checkpoint-restore/criu/issues/2021
> [3] https://github.com/checkpoint-restore/criu/issues/2021#issuecomment-1346971967
> 
>>>
>>> Further ... isn't CRIU already using uffd in some cases? ...documentation
>>> mentions [1] that it is used for "lazy (or post-copy) restore in CRIU". At least
>>> if the documentation is correct and its actually implemented.
>>>
>>
>> Shivansh, same question - do you know the current CRIU status/plans for using
>> uffd-wp instead of soft-dirty? If CRIU doesn't currently implement it and has no
>> current plans to, how can we guage interest in making a plan?
>>
> 
> While I cannot gauge whether the maintainers or main contributors of CRIU plan on using uffd-wp instead of soft-dirty in the future, I can tell you that there is no currently open issue to track that work, and whenever anyone in the past has asked about ARM64 pre-dump support to CRIU (which is the feature that uses soft-dirty/would use uffd-wp), they've always just said it's not supported - but that they do want the feature [4].
> 
> So in summary, they want the feature, but no one is working on implementing it (either with soft-dirty or with uffd-wp).
> 
> I doubt that CRIU would have any issues with adding the feature via soft-dirty (since, as shown in [4] they're interested in it), but as for using uffd-wp they definitely haven't shown any interest thus far. Based on the fact that it would be a very significant amount of work and it would really only be for ARM64 support (which they're already fine without), I'd be very surprised if they were interested in pursuing it.
> 

Of course, nobody wants to do the work. But that doesn't mean that the 
kernel has to do the work :)

If there are some major challenges why it cannot possible be done with 
uffd-wp (unfixable), that's a different story.

> [4] https://github.com/checkpoint-restore/criu/issues/1859#issuecomment-1972674047
> 
>>>
>>>>
>>>>> But I'll throw in another idea: do we really need soft-dirty and uffd-wp to
>>>>> exist at the same time in the same process (or the VMA?). In theory, we
>>
>> My instinct is that MUXing a PTE bit like this will lead to some subtle problems
>> that won't appear on arches that support either one or both of the features
>> independently and unconditionally. Surely better to limit ourselves to either
>> "arm64 will only support uffd-wp" or "arm64 will support both uffd-wp and
>> soft-dirty". That way, we could move ahead with reviewing/merging the uffd-wp
>> support asynchronously to deciding whether we want to support soft-dirty.
>>
> 
> My personal preference is having both approaches supported - especially in the context of CRIU since I doubt they'll be willing to rewrite all of the dumping and restore logic just for ARM64 support.

Sure, nobody does any work unless they are forced to.

But this is something that arm64 maintainers will have to decide.

Let's start with uffd-wp that has other well-known users that could 
benefit (e.g., QEMU background snapshots).

-- 
Cheers,

David / dhildenb

Powered by blists - more mailing lists