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 55B23C433E0 for ; Tue, 12 Jan 2021 17:00:31 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id DDD3623123 for ; Tue, 12 Jan 2021 17:00:30 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DDD3623123 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 237DA8D00F9; Tue, 12 Jan 2021 12:00:30 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1E8868D00F6; Tue, 12 Jan 2021 12:00:30 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0D6908D00F9; Tue, 12 Jan 2021 12:00:30 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0043.hostedemail.com [216.40.44.43]) by kanga.kvack.org (Postfix) with ESMTP id EAA458D00F6 for ; Tue, 12 Jan 2021 12:00:29 -0500 (EST) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id AD882181AEF21 for ; Tue, 12 Jan 2021 17:00:29 +0000 (UTC) X-FDA: 77697736578.17.touch78_191110227517 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin17.hostedemail.com (Postfix) with ESMTP id 75039180D0186 for ; Tue, 12 Jan 2021 17:00:29 +0000 (UTC) X-HE-Tag: touch78_191110227517 X-Filterd-Recvd-Size: 4343 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf49.hostedemail.com (Postfix) with ESMTP for ; Tue, 12 Jan 2021 17:00:28 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 7FF9F23127 for ; Tue, 12 Jan 2021 17:00:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1610470827; bh=tCbxKujI10pNeT2qDClnRO79KvrvLxikcI5B4muZGVA=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=H3b3afDJblxw0v2aj4WYAzWL2vg9qBy6rnfIwmO9afYS1w/rlouGjfbZjfupbATS5 bH/yMFzEj2JOnS7IENRCwWToTMw1sHlARCrUFS9Gtc0ZN8OB0LYIOOy9jpgToCfZTV LoEgfBUyVSLASvLwNCKwOT4IyAUPipC6AHfKNhfpAZSQQBx2P/RjrrPXUgYOhae85k mrxvZeVTBFQkGSuxXdfdwIbfeOdTHOX/5TAJq30PjM0kw9vcCSUGiKg2Obcv10zPar R5yS1xBR/BdbSehxgX7KG/9GhRwHZjroEtihovqu6ySQ3QFLvQwRHEeZtMO+vIpdxP GdrBM8aeF3OmA== Received: by mail-ed1-f44.google.com with SMTP id dk8so3130061edb.1 for ; Tue, 12 Jan 2021 09:00:27 -0800 (PST) X-Gm-Message-State: AOAM530RZTilEfg7LylIUsUr8OfO1Ecu8VcSNfecOJaLMvxyStlMeldW YT6CxIQuPFaZCMZGxax7ex8HXc2/+FcbTg14CY1MxQ== X-Google-Smtp-Source: ABdhPJyGazjWMMRy7pPL3L2Y5X0VrBDF1yaBeJLIhIG+bd9wRtrykiTD4iIdg3jGAxS1Cd1twFgKjVVkxFxGmAonX6A= X-Received: by 2002:a05:6402:a5b:: with SMTP id bt27mr87467edb.222.1610470826025; Tue, 12 Jan 2021 09:00:26 -0800 (PST) MIME-Version: 1.0 References: <20210111214452.1826-2-tony.luck@intel.com> <20210111222057.GA2369@agluck-desk2.amr.corp.intel.com> In-Reply-To: <20210111222057.GA2369@agluck-desk2.amr.corp.intel.com> From: Andy Lutomirski Date: Tue, 12 Jan 2021 09:00:14 -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: Borislav Petkov , X86 ML , Andrew Morton , Peter Zijlstra , Darren Hart , Andy Lutomirski , LKML , linux-edac , Linux-MM Content-Type: text/plain; charset="UTF-8" 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 Jan 11, 2021, at 2:21 PM, Luck, Tony wrote: > > =EF=BB=BFOn Mon, Jan 11, 2021 at 02:11:56PM -0800, Andy Lutomirski wrote: >> >>>> On Jan 11, 2021, at 1:45 PM, Tony Luck wrote: >>> >>> =EF=BB=BFRecovery action when get_user() triggers a machine check uses = the fixup >>> path to make get_user() return -EFAULT. Also queue_task_work() sets up >>> so that kill_me_maybe() will be called on return to user mode to send a >>> SIGBUS to the current process. >>> >>> But there are places in the kernel where the code assumes that this >>> EFAULT return was simply because of a page fault. The code takes some >>> action to fix that, and then retries the access. This results in a seco= nd >>> machine check. >>> >>> While processing this second machine check queue_task_work() is called >>> again. But since this uses the same callback_head structure that >>> was used in the first call, the net result is an entry on the >>> current->task_works list that points to itself. >> >> Is this happening in pagefault_disable context or normal sleepable fault= context? If the latter, maybe we should reconsider finding a way for the = machine check code to do its work inline instead of deferring it. > > The first machine check is in pagefault_disable() context. > > static int get_futex_value_locked(u32 *dest, u32 __user *from) > { > int ret; > > pagefault_disable(); > ret =3D __get_user(*dest, from); I have very mixed feelings as to whether we should even try to recover from the first failure like this. If we actually want to try to recover, perhaps we should instead arrange for the second MCE to recover successfully instead of panicking. --Andy > pagefault_enable(); > > return (ret =3D=3D -ENXIO) ? ret : ret ? -EFAULT : 0; > } > > -Tony