From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 32B8DC54FCF for ; Mon, 20 Apr 2020 20:23:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1BD70206B9 for ; Mon, 20 Apr 2020 20:23:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726642AbgDTUXg (ORCPT ); Mon, 20 Apr 2020 16:23:36 -0400 Received: from mga07.intel.com ([134.134.136.100]:47233 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725897AbgDTUXf (ORCPT ); Mon, 20 Apr 2020 16:23:35 -0400 IronPort-SDR: vlQ6p71zo0Bt3ERSVm9sWXDE92Ia/VM+onRrdWRMOcAD9MV1arrMGWQeFTUPOaKWkQ6RIGnFbB LjF8+KubFQUw== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Apr 2020 13:23:34 -0700 IronPort-SDR: dwbx/a0msG2TP6vaKuk6gKGzkILRzrBv45iy3zonm01WA2AXycd2VV41ZeD6i223Je/0lLuoIA PjXGlNLibkjw== X-IronPort-AV: E=Sophos;i="5.72,407,1580803200"; d="scan'208";a="456502146" Received: from agluck-desk2.sc.intel.com (HELO agluck-desk2.amr.corp.intel.com) ([10.3.52.68]) by fmsmga006-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Apr 2020 13:23:34 -0700 Date: Mon, 20 Apr 2020 13:23:32 -0700 From: "Luck, Tony" To: Linus Torvalds Cc: Dan Williams , Andy Lutomirski , Thomas Gleixner , Ingo Molnar , X86 ML , stable , Borislav Petkov , "H. Peter Anvin" , Peter Zijlstra , Erwin Tsaur , Linux Kernel Mailing List , linux-nvdimm Subject: Re: [PATCH] x86/memcpy: Introduce memcpy_mcsafe_fast Message-ID: <20200420202332.GA30160@agluck-desk2.amr.corp.intel.com> References: <67FF611B-D10E-4BAF-92EE-684C83C9107E@amacapital.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 20, 2020 at 01:07:09PM -0700, Linus Torvalds wrote: > On Mon, Apr 20, 2020 at 12:29 PM Dan Williams wrote: > > > > I didn't consider asynchronous to be > > better because that means there is a gap between when the data > > corruption is detected and when it might escape the system that some > > external agent could trust the result and start acting on before the > > asynchronous signal is delivered. > > The thing is, absolutely nobody cares whether you start acting on the > wrong data or not. I think they do. If the result of the wrong data has already been sent out the network before you process the signal, then you will need far smarter application software than has ever been written to hunt it down and stop the spread of the bogus result. Stopping dead on the instruction before it consumes the data means you can "recover" by killing just one process, or just one VMM guest. I'm in total agreement the machine check (especially broadcast) was a bad choice for how to "stop on a dime". But I can't see how you could possibly decide what to do if you let thousands of instructions retire based on a bad data value before you even know that it happened. -Tony