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=-3.8 required=3.0 tests=BAYES_00, 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 C4B1BC433E6 for ; Wed, 13 Jan 2021 01:51:00 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0E55C2310F for ; Wed, 13 Jan 2021 01:50:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0E55C2310F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 26CD66B0121; Tue, 12 Jan 2021 20:50:59 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 21CFE6B0123; Tue, 12 Jan 2021 20:50:59 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1336A6B0125; Tue, 12 Jan 2021 20:50:59 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0005.hostedemail.com [216.40.44.5]) by kanga.kvack.org (Postfix) with ESMTP id F1E096B0121 for ; Tue, 12 Jan 2021 20:50:58 -0500 (EST) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id B2E621EE6 for ; Wed, 13 Jan 2021 01:50:58 +0000 (UTC) X-FDA: 77699073396.10.spade69_33047d02751a Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin10.hostedemail.com (Postfix) with ESMTP id 94DEB16A0DD for ; Wed, 13 Jan 2021 01:50:58 +0000 (UTC) X-HE-Tag: spade69_33047d02751a X-Filterd-Recvd-Size: 2994 Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by imf01.hostedemail.com (Postfix) with ESMTP for ; Wed, 13 Jan 2021 01:50:57 +0000 (UTC) IronPort-SDR: h524yEXQZFG6/2yel3KUF6YTTdpzE+eKdMRLFslTeQFFRfzNkjplnr8LDLqEylrleJWXCQxk7D 1fAPxJUKkqHw== X-IronPort-AV: E=McAfee;i="6000,8403,9862"; a="196768981" X-IronPort-AV: E=Sophos;i="5.79,343,1602572400"; d="scan'208";a="196768981" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Jan 2021 17:50:55 -0800 IronPort-SDR: ZFOkMzVU33jKa2RmLCRY0kRI4IaMNxOhu7eCj80pScZgPfEYxXJmRAHq+wZT5WNP/ndSisrTsM AJeGenWJBL6w== X-IronPort-AV: E=Sophos;i="5.79,343,1602572400"; d="scan'208";a="424384839" Received: from agluck-desk2.sc.intel.com (HELO agluck-desk2.amr.corp.intel.com) ([10.3.52.68]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Jan 2021 17:50:54 -0800 Date: Tue, 12 Jan 2021 17:50:53 -0800 From: "Luck, Tony" To: Andy Lutomirski Cc: Andy Lutomirski , Borislav Petkov , X86 ML , Andrew Morton , Peter Zijlstra , Darren Hart , LKML , linux-edac , Linux-MM Subject: Re: [PATCH v2 1/3] x86/mce: Avoid infinite loop for copy from user recovery Message-ID: <20210113015053.GA21587@agluck-desk2.amr.corp.intel.com> References: <20210112205207.GA18195@agluck-desk2.amr.corp.intel.com> <38AF04BE-7F39-450F-8C26-879C9934E3D6@amacapital.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <38AF04BE-7F39-450F-8C26-879C9934E3D6@amacapital.net> Content-Transfer-Encoding: quoted-printable 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: On Tue, Jan 12, 2021 at 02:04:55PM -0800, Andy Lutomirski wrote: > > But we know that the fault happend in a get_user() or copy_from_user(= ) call > > (i.e. an RIP with an extable recovery address). Does context switch > > access user memory? >=20 > No, but NMI can. >=20 > The case that would be very very hard to deal with is if we get an NMI = just before IRET/SYSRET and get #MC inside that NMI. >=20 > What we should probably do is have a percpu list of pending memory fail= ure cleanups and just accept that we=E2=80=99re going to sometimes get a = second MCE (or third or fourth) before we can get to it. >=20 > Can we do the cleanup from an interrupt? IPI-to-self might be a credib= le approach, if so. You seem to be looking for a solution that is entirely contained within the machine check handling code. Willing to allow for repeated machine checks from the same poison address in order to achieve that. I'm opposed to mutliple machine checks. Willing to make some changes in core code to avoid repeated access to the same poison location. We need a tie-breaker. -Tony