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=-6.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 A1C37C433E0 for ; Tue, 12 Jan 2021 18:57:24 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1597522CE3 for ; Tue, 12 Jan 2021 18:57:23 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1597522CE3 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 3254C6B00A1; Tue, 12 Jan 2021 13:57:23 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2D43D6B00A2; Tue, 12 Jan 2021 13:57:23 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1E9766B00A3; Tue, 12 Jan 2021 13:57:23 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0126.hostedemail.com [216.40.44.126]) by kanga.kvack.org (Postfix) with ESMTP id 070556B00A1 for ; Tue, 12 Jan 2021 13:57:23 -0500 (EST) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id B80311EE6 for ; Tue, 12 Jan 2021 18:57:22 +0000 (UTC) X-FDA: 77698031124.26.brass80_5a0904327517 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin26.hostedemail.com (Postfix) with ESMTP id 93DC41804B660 for ; Tue, 12 Jan 2021 18:57:22 +0000 (UTC) X-HE-Tag: brass80_5a0904327517 X-Filterd-Recvd-Size: 4392 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf39.hostedemail.com (Postfix) with ESMTP for ; Tue, 12 Jan 2021 18:57:21 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id A7A2A23122 for ; Tue, 12 Jan 2021 18:57:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1610477840; bh=qEYVDk2n6QAVg4WiGfYhBfpW3XJsw9qR39XuOVUrciE=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=ts9DrtUAA1GEpN4BuSOqiX5K2zQg2/sGWa1F3QirrwvHXVOEAd1AfDxYSQeqar5Ko yvfmuc357OHy4j7mJ1DKb5GE0t5vFMWmDXNbvRaSJPMKcll/bKH5Hclg5Krv1HCEW4 sQ4BOSIo8jDZ+8ZBlPdp5N+t51RCsHUob2Yt41LC9Zjdt2BRoShsEHXwYwcLV/FamB X/cT3vGNbZV+qzEl53lVT8jwPesUnkRfbw+eY+BO+2Srvh+8ycMttP1Y5eI9JR1opa tlvZWoYxgbynFHHSEHRfTxHygGN6LsrfetKkMRm/KhREcXSJTiKgs1ZUQXQGFiVwFE WhruniVKugXiQ== Received: by mail-ej1-f52.google.com with SMTP id ga15so5030285ejb.4 for ; Tue, 12 Jan 2021 10:57:20 -0800 (PST) X-Gm-Message-State: AOAM530TnzGPNMR8xRWoZqjm84hy58xg3OYB/Yx6gFIb2t77G01FDh04 efWa84RaNhWOHJktpOvkvTotRjdlKbu8WJFITnim/Q== X-Google-Smtp-Source: ABdhPJwa1SLrf/AXA3+Oh0ElF/YK5IYtuk315jrUdJu8T9NDyOQ0b+aBKyIKdtGyqoYP5BsFhTJwcYko3HQmw2dlaIk= X-Received: by 2002:a17:906:351a:: with SMTP id r26mr174708eja.204.1610477839172; Tue, 12 Jan 2021 10:57:19 -0800 (PST) MIME-Version: 1.0 References: <20210111214452.1826-2-tony.luck@intel.com> <20210111222057.GA2369@agluck-desk2.amr.corp.intel.com> <20210112171628.GA15664@agluck-desk2.amr.corp.intel.com> <20210112182357.GA16390@agluck-desk2.amr.corp.intel.com> In-Reply-To: <20210112182357.GA16390@agluck-desk2.amr.corp.intel.com> From: Andy Lutomirski Date: Tue, 12 Jan 2021 10:57:07 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 1/3] x86/mce: Avoid infinite loop for copy from user recovery To: "Luck, Tony" Cc: Andy Lutomirski , Borislav Petkov , X86 ML , Andrew Morton , Peter Zijlstra , Darren Hart , LKML , linux-edac , Linux-MM Content-Type: text/plain; charset="UTF-8" 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 10:24 AM Luck, Tony wrote: > > 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. That seems scary, especially if we're in the middle of a context switch when this happens. We *could* make it work, but I'm not at all convinced it's wise. > > 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 This would need to be integrated with something much more local IMO. Maybe it could be scoped to pagefault_disable()/pagefault_enable()? --Andy