Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp6729485iob; Wed, 11 May 2022 04:14:25 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwNng8BNwam6SXCW7rZrkb4SQpxhzS2uKPahqNbEvAplIAivgaq0/engYu1LtEOKJjBNWNB X-Received: by 2002:a50:fe1a:0:b0:425:e276:5adf with SMTP id f26-20020a50fe1a000000b00425e2765adfmr28055716edt.284.1652267665672; Wed, 11 May 2022 04:14:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652267665; cv=none; d=google.com; s=arc-20160816; b=p2n+31v2+vdZchnPrE8pbVdjd9iQ1jgAHbZSRvsl+Ak0DA7xbzOBZXhW0JJko6SaVV XQWwtDCe2EwqF+eYgtr83/5gyXWp0gZqjTERIsokJumzOAAy8Btu/p8WlD04t8Bp76nK EFaOS0qTL7Tk+QPFwNQCPPstRtJxY5yZdabunrzePcxKOLMBNSRwI5z5d/sss4uaYlBm eza3H7VkZDq5uZNGGkw4cE92IrWJheXlNbekuMpQ0JBH20tLP5rgIDsoGBAww+wh6Oy7 Ze5uCR/jVz5xlBKYgrFfNPVMYHCuLRVIUj9ktsHr9QQnx+fskbbdAI9bi/akEp+OJEdO t+SA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=elq3ZqCelpCSxkkjk1LXdyA6w9hgB+SCHXKMgxWGx/U=; b=fkBWbjnzMw1I6wKyXseifY/9zBogmsL07+Q0qlBPcHqKNtXnVJ3qzlHp8l/rWhBkih zy84RwFDTrypocDIFiyFVPXBrLUzvs2Yogm2rxOLT4wy0xPUUK8Eka5nBknBPIFfK2I9 1jmK0A9l+h/SWUag/BNGB8LIZfpP8NNei7wB8NDxobQCZR8traGJsijpwzftZiOEJQq2 XfQnHc8WDWXXiZ9yfiV0bKDT8u41a/qgyQLelkquiD5DO93oxcz+JsT+lh7X2boK5E9m 94iM3X2jqmglFS3pyT0tbE9rR94DN7qyXTU/M55Xv1yd6tZdbINuZZ40CjAGCtF0IJHY dUJA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20210112.gappssmtp.com header.s=20210112 header.b=f0WEcC7j; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id sh6-20020a1709076e8600b006f435477a96si2068049ejc.557.2022.05.11.04.13.57; Wed, 11 May 2022 04:14:25 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel-com.20210112.gappssmtp.com header.s=20210112 header.b=f0WEcC7j; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239769AbiEKD5L (ORCPT + 99 others); Tue, 10 May 2022 23:57:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39494 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242058AbiEKD4r (ORCPT ); Tue, 10 May 2022 23:56:47 -0400 Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 20FA45DBE7 for ; Tue, 10 May 2022 20:56:32 -0700 (PDT) Received: by mail-pl1-x636.google.com with SMTP id i1so666530plg.7 for ; Tue, 10 May 2022 20:56:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=elq3ZqCelpCSxkkjk1LXdyA6w9hgB+SCHXKMgxWGx/U=; b=f0WEcC7jjPTFG6Q6v9mT/VTbUk6akakqKqThuRBA10OtcmKjJs4FotEBdprRTmZrZF Kb8j00IvxlaVvxLhVF+olvEM7z068yqNY7DUksi25Wuhc+ittQMbF3sNNuMlrjp0trft jPe+SBWtYADIgBt1U9crcisYDlPyJy9V3ts222QP9S+ZNj9WdGzgEwTfgBNGgl9lTyX0 2Fv+/xdOFKMtT6Hvk7/sOzspO4aPku8B/XAFXgUu6zqe5yJcQO9LXB8JSfcNQzqAzBt6 y50LLDXRRm0M8Qj3TiD3Vhrh3vbutMS5qxe2s2RBw/glkC+5rS+kVBVhvbLF5i3xYVL7 tJ4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=elq3ZqCelpCSxkkjk1LXdyA6w9hgB+SCHXKMgxWGx/U=; b=y58oan3DG/eLpXp6HtxMcyRxTHFIV/3iDMZZOwC7lHUq6gGudZbjlvo4dnTtyCR03C Nmk6G3EK++agbak2d8/SemanHT0fQ9eCaGUBFeCQv4Pd/iMhGVh+Py5Z+UL4xr7lb7XU vydhpj5kdP8O8kF2Pu/tfvdcEcnI0QuN1wcibLb19NHF8+sUVaDe9KZoUvF1KrwO2hC/ RFKTlHnM1P/r5XlcJ1Ib5/LPZc6W2p5KpMVFRg+9wryJ4gpYkX+bWjoviHK1F+mcrI5y plSJikET6Wx6kRYxqeAseeOgUbjrTUBLctczgbQsUfak0cVaelqNBnj3yYchg7E9pUcX ZNkQ== X-Gm-Message-State: AOAM531b9/Mm8PVaF/aGpYiBoYRROvDmq1XfWCBVty+ZSeoYY3hRO38M 9KVobs/wdhOh2jApWGWQZLEGUP+9oo9wDLMaY1pQLw== X-Received: by 2002:a17:902:da8b:b0:15e:c0e8:d846 with SMTP id j11-20020a170902da8b00b0015ec0e8d846mr23539490plx.34.1652241391912; Tue, 10 May 2022 20:56:31 -0700 (PDT) MIME-Version: 1.0 References: <20220422224508.440670-1-jane.chu@oracle.com> <20220422224508.440670-4-jane.chu@oracle.com> In-Reply-To: From: Dan Williams Date: Tue, 10 May 2022 20:56:21 -0700 Message-ID: Subject: Re: [PATCH v9 3/7] mce: fix set_mce_nospec to always unmap the whole page To: Jane Chu , Borislav Petkov Cc: Christoph Hellwig , Dave Hansen , Peter Zijlstra , Andy Lutomirski , david , "Darrick J. Wong" , linux-fsdevel , Linux NVDIMM , Linux Kernel Mailing List , X86 ML , Vishal L Verma , Dave Jiang , Alasdair Kergon , Mike Snitzer , device-mapper development , "Weiny, Ira" , Matthew Wilcox , Vivek Goyal , "Luck, Tony" , Jue Wang Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE, T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 22, 2022 at 4:25 PM Dan Williams wrote: > > [ Add Tony as the originator of the whole_page() logic and Jue who > reported the issue that lead to 17fae1294ad9 x86/{mce,mm}: Unmap the > entire page if the whole page is affected and poisoned ] > > > On Fri, Apr 22, 2022 at 3:46 PM Jane Chu wrote: > > > > The set_memory_uc() approach doesn't work well in all cases. > > As Dan pointed out when "The VMM unmapped the bad page from > > guest physical space and passed the machine check to the guest." > > "The guest gets virtual #MC on an access to that page. When > > the guest tries to do set_memory_uc() and instructs cpa_flush() > > to do clean caches that results in taking another fault / exception > > perhaps because the VMM unmapped the page from the guest." > > > > Since the driver has special knowledge to handle NP or UC, > > mark the poisoned page with NP and let driver handle it when > > it comes down to repair. > > > > Please refer to discussions here for more details. > > https://lore.kernel.org/all/CAPcyv4hrXPb1tASBZUg-GgdVs0OOFKXMXLiHmktg_kFi7YBMyQ@mail.gmail.com/ > > > > Now since poisoned page is marked as not-present, in order to > > avoid writing to a not-present page and trigger kernel Oops, > > also fix pmem_do_write(). > > > > Fixes: 284ce4011ba6 ("x86/memory_failure: Introduce {set, clear}_mce_nospec()") > > Reviewed-by: Christoph Hellwig > > Reviewed-by: Dan Williams > > Signed-off-by: Jane Chu Boris, This is the last patch in this set that needs an x86 maintainer ack. Since you have been involved in the history for most of this, mind giving it an ack so I can pull it in for v5.19? Let me know if you want a resend.