We further recently added a new UFFD_FEATURE_WP_ASYNC feature as part of [2], because getting soft-dirty return reliable results in some cases turned out rather hard to fix.
But it sounds like the current soft-dirty semantic is sufficient for CRIU on other arches? If I understood correctly from my brief scan of the linked post, the problem is that soft-dirty can sometimes provide false-positives? So could result in uneccessary copy, but never lost data?
Yes, it seems to be good enough for them in that regard I think.
[...]
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.
Yes. MUXing would require some work, but likely better than wasting 1/64 PTE space on a corner case feature with one famous user that might be able to port to an alternative with other active users (growing ;) ).
Anyhow, I don't maintain arm64 code and we have to carry that baggage in the core either way for the time being ...