Re: [PATCH v1 0/5] arm64/mm: uffd write-protect and soft-dirty tracking

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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





[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux