On Wed, Jun 17, 2020 at 05:31:58PM -0700, Dan Williams wrote:
No changes since v5 [1], just rebased to v5.8-rc1. No comments since that posting back at the end of May either, will continue to re-post weekly, I am otherwise at a loss for what else to do to move this forward. Should it go through Andrew since it's across PPC and x86? Thanks again to Michael for the PPC acks.
The primary motivation to go touch memcpy_mcsafe() is that the existing benefit of doing slow "handle with care" copies is obviated on newer CPUs. With that concern lifted it also obviates the need to continue to update the MCA-recovery capability detection code currently gated by "mcsafe_key". Now the old "mcsafe_key" opt-in to perform the copy with concerns for recovery fragility can instead be made an opt-out from the default fast copy implementation (enable_copy_mc_fragile()).
The discussion with Linus on the first iteration of this patch identified that memcpy_mcsafe() was misnamed relative to its usage. The new names copy_mc_to_user() and copy_mc_to_kernel() clearly indicate the intended use case and lets the architecture organize the implementation accordingly.
For both powerpc and x86 a copy_mc_generic() implementation is added as the backend for these interfaces.
Patches are relative to v5.8-rc1. It has a recent build success notification from the kbuild robot and is passing local nvdimm tests.
Looks good to me. I tested on a Broadwell generation system (i.e. one of the system you now list as "fragile") and injecting uncorrected errors into buffers that are then copied using copy_mc_to_kernel() result in recovered machine checks with the return value correctly indicating the amount remaining.
Reviewed-by: Tony Luck tony.luck@intel.com
-Tony