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 ...
--
Cheers,
David / dhildenb