From patchwork Mon Oct 18 20:25:35 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Luck, Tony" X-Patchwork-Id: 12567991 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F01FBC433F5 for ; Mon, 18 Oct 2021 20:25:53 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8E9DC61212 for ; Mon, 18 Oct 2021 20:25:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 8E9DC61212 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id B3628900004; Mon, 18 Oct 2021 16:25:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AE55C900003; Mon, 18 Oct 2021 16:25:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9D463900004; Mon, 18 Oct 2021 16:25:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0025.hostedemail.com [216.40.44.25]) by kanga.kvack.org (Postfix) with ESMTP id 90536900003 for ; Mon, 18 Oct 2021 16:25:52 -0400 (EDT) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 451238249980 for ; Mon, 18 Oct 2021 20:25:52 +0000 (UTC) X-FDA: 78710689344.25.2F6097E Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by imf13.hostedemail.com (Postfix) with ESMTP id EB09B10467F5 for ; Mon, 18 Oct 2021 20:25:48 +0000 (UTC) X-IronPort-AV: E=McAfee;i="6200,9189,10141"; a="228307004" X-IronPort-AV: E=Sophos;i="5.85,382,1624345200"; d="scan'208";a="228307004" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Oct 2021 13:25:49 -0700 X-IronPort-AV: E=Sophos;i="5.85,382,1624345200"; d="scan'208";a="493758159" Received: from agluck-desk2.sc.intel.com ([10.3.52.146]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Oct 2021 13:25:49 -0700 From: Tony Luck To: "Rafael J. Wysocki" , naoya.horiguchi@nec.com Cc: Andrew Morton , Sean Christopherson , Jarkko Sakkinen , Dave Hansen , Cathy Zhang , linux-sgx@vger.kernel.org, linux-acpi@vger.kernel.org, linux-mm@kvack.org, Tony Luck Subject: [PATCH v10 0/7] Basic recovery for machine checks inside SGX Date: Mon, 18 Oct 2021 13:25:35 -0700 Message-Id: <20211018202542.584115-1-tony.luck@intel.com> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20211011185924.374213-1-tony.luck@intel.com> References: <20211011185924.374213-1-tony.luck@intel.com> MIME-Version: 1.0 X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: EB09B10467F5 X-Stat-Signature: s8ssw6dti3gj465s8upqbb811uh7geqx Authentication-Results: imf13.hostedemail.com; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=intel.com (policy=none); spf=none (imf13.hostedemail.com: domain of tony.luck@intel.com has no SPF policy when checking 134.134.136.65) smtp.mailfrom=tony.luck@intel.com X-HE-Tag: 1634588748-263161 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: v10 (based on v5.15-rc6) Changes since v9: ACPI reviewers (Rafael): No changes to parts 6 & 7. MM reviewers (Horiguchi-san): No changes to part 5. Jarkko: Added Reviewed-by tags to remaining patches. N.B. I kept the tags on parts 1, 3, 4 because changes based on Sean feedback didn't seem consequential. Please let me know if you disagree and see new problems introduced by me trying to follow Sean's feedback. Sean: 1) Reverse the polarity of the neutron flow (sorry, Dr Who fan will always autocomplete a sentence that begins "reverse the polarity" that way.) Actual change is for the new flag bit. Instead of marking in-use pages with the new bit, mark free pages instead. This avoids the weirdness where I marked the pages on the dirty list as "in-use", when clearly they are not. 2) Race conditions adding poisoned pages to the global list of poisoned pages. Fixed this by changing from a global list to a per-node list. Additions are protected by the node->lock. 3) Use list_move() instead of list_del(); list_add() Fixed both places I used this idiom. 4) Race looking at page->poison when cleaning dirty pages. Added a comment documenting why losing this race isn't overly harmful. Tony Luck (7): x86/sgx: Add new sgx_epc_page flag bit to mark free pages x86/sgx: Add infrastructure to identify SGX EPC pages x86/sgx: Initial poison handling for dirty and free pages x86/sgx: Add SGX infrastructure to recover from poison x86/sgx: Hook arch_memory_failure() into mainline code x86/sgx: Add hook to error injection address validation x86/sgx: Add check for SGX pages to ghes_do_memory_failure() .../firmware-guide/acpi/apei/einj.rst | 19 +++ arch/x86/include/asm/processor.h | 8 ++ arch/x86/include/asm/set_memory.h | 4 + arch/x86/kernel/cpu/sgx/main.c | 113 +++++++++++++++++- arch/x86/kernel/cpu/sgx/sgx.h | 7 +- drivers/acpi/apei/einj.c | 3 +- drivers/acpi/apei/ghes.c | 2 +- include/linux/mm.h | 14 +++ mm/memory-failure.c | 19 ++- 9 files changed, 179 insertions(+), 10 deletions(-) base-commit: 519d81956ee277b4419c723adfb154603c2565ba