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 5BCB4C433DB for ; Tue, 12 Jan 2021 18:24:04 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id EB6692311A for ; Tue, 12 Jan 2021 18:24:03 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EB6692311A 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 2EE006B0096; Tue, 12 Jan 2021 13:24:03 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 29DA76B0099; Tue, 12 Jan 2021 13:24:03 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 165D86B009A; Tue, 12 Jan 2021 13:24:03 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0044.hostedemail.com [216.40.44.44]) by kanga.kvack.org (Postfix) with ESMTP id 01A8E6B0096 for ; Tue, 12 Jan 2021 13:24:02 -0500 (EST) Received: from smtpin12.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id BD0F5180AD817 for ; Tue, 12 Jan 2021 18:24:02 +0000 (UTC) X-FDA: 77697947124.12.owner31_210cc2827517 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin12.hostedemail.com (Postfix) with ESMTP id 9E0A318013031 for ; Tue, 12 Jan 2021 18:24:02 +0000 (UTC) X-HE-Tag: owner31_210cc2827517 X-Filterd-Recvd-Size: 3481 Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by imf43.hostedemail.com (Postfix) with ESMTP for ; Tue, 12 Jan 2021 18:24:01 +0000 (UTC) IronPort-SDR: D5xzxhHeMSCGIndWSiOUArxt9wU5pXN2asTSTaAEOui1k2hZZOrptlcIcPEHf8mdU82L3uJkxW qI6btEAYvYhA== X-IronPort-AV: E=McAfee;i="6000,8403,9862"; a="178180570" X-IronPort-AV: E=Sophos;i="5.79,342,1602572400"; d="scan'208";a="178180570" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Jan 2021 10:23:58 -0800 IronPort-SDR: ohLXLssT4T57MYIoJBHSlpn4WHeghfurRajLgrIXE/VuuJ6lqmocvtLygDAzEJMDKX5wobDyWj PlGu+p9zMXzA== X-IronPort-AV: E=Sophos;i="5.79,342,1602572400"; d="scan'208";a="381521649" Received: from agluck-desk2.sc.intel.com (HELO agluck-desk2.amr.corp.intel.com) ([10.3.52.68]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Jan 2021 10:23:58 -0800 Date: Tue, 12 Jan 2021 10:23:57 -0800 From: "Luck, Tony" To: Andy Lutomirski Cc: 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: <20210112182357.GA16390@agluck-desk2.amr.corp.intel.com> References: <20210111214452.1826-2-tony.luck@intel.com> <20210111222057.GA2369@agluck-desk2.amr.corp.intel.com> <20210112171628.GA15664@agluck-desk2.amr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 09:21:21AM -0800, Andy Lutomirski wrote: > Well, we need to do *something* when the first __get_user() trips the > #MC. It would be nice if we could actually fix up the page tables > inside the #MC handler, but, if we're in a pagefault_disable() context > we might have locks held. Heck, we could have the pagetable lock > held, be inside NMI, etc. Skipping the task_work_add() might actually > make sense if we get a second one. > > We won't actually infinite loop in pagefault_disable() context -- if > we would, then we would also infinite loop just from a regular page > fault, too. Fixing the page tables inside the #MC handler to unmap the poison page would indeed be a good solution. But, as you point out, not possible because of locks. Could we take a more drastic approach? We know that this case the kernel is accessing a user address for the current process. Could the machine check handler just re-write %cr3 to point to a kernel-only page table[1]. I.e. unmap the entire current user process. Then any subsequent access to user space will page fault. Maybe have a flag in the task structure to help the #PF handler understand what just happened. The code we execute in the task_work handler can restore %cr3 -Tony [1] Does such a thing already exist? If not, I'd need some help/pointers to create it.