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. > > [1]: http://lore.kernel.org/r/159062136234.2192412.7285856919306307817.stgit@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx > > --- > > 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@xxxxxxxxx> -Tony
