Re: [PATCH v6 0/2] Renovate memcpy_mcsafe with copy_mc_to_{user, kernel}

[Luck, Tony]

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