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 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 4947CC433DB for ; Thu, 14 Jan 2021 17:23:00 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C98C923B52 for ; Thu, 14 Jan 2021 17:22:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C98C923B52 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 5E53A8D00F5; Thu, 14 Jan 2021 12:22:59 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 56EA98D00F0; Thu, 14 Jan 2021 12:22:59 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3E8308D00F5; Thu, 14 Jan 2021 12:22:59 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0105.hostedemail.com [216.40.44.105]) by kanga.kvack.org (Postfix) with ESMTP id 24FDB8D00F0 for ; Thu, 14 Jan 2021 12:22:59 -0500 (EST) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id E20AC3621 for ; Thu, 14 Jan 2021 17:22:58 +0000 (UTC) X-FDA: 77705050836.02.crowd35_1e1663727528 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin02.hostedemail.com (Postfix) with ESMTP id C8B6410097AA0 for ; Thu, 14 Jan 2021 17:22:58 +0000 (UTC) X-HE-Tag: crowd35_1e1663727528 X-Filterd-Recvd-Size: 4340 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf24.hostedemail.com (Postfix) with ESMTP for ; Thu, 14 Jan 2021 17:22:58 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 12A9623B52 for ; Thu, 14 Jan 2021 17:22:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1610644977; bh=Lq+/xcRpcAsTNgRFXMjtZMsufCcASKMREtzWScmKsx8=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=eOgVUgX5LmAOS+3Pf3BfXtV1UbVoa8q+bsLMhWyEOWKBUb183XZQPToLJNlO3CLwL 7H6+rq5uydSQYKzR/oNK5M3/JIa2fMJawFXWMVSTOmmhRi21OCGE768j4VY5OZ8DKt 1DHHluBgRO8LxHXdCYb3vGcaJ9UOtzVdCTVHV7aflPj1WyXCz4v9/gM2obCqHUx35F /hhc5wKqhLy316gnKhnmyDfvjXgO3HJkLadFDmd6Jy0Xx3XN50RrC06xMZCVh3sVKn E3JOa+BYyCd+Rq++dJMDn52dEF76AwveSpioiiIlNc8b1VXuDFqq2rNNzoErCWAYu5 BvuyPq+drm9Gg== Received: by mail-ed1-f47.google.com with SMTP id u19so6566498edx.2 for ; Thu, 14 Jan 2021 09:22:56 -0800 (PST) X-Gm-Message-State: AOAM533vP2MYha67NLeRacjfue9sd8DIScyjyyVzb5oJO4YkJAbVParM NaFj7f2AYCPMrG3xBAZHJcvWPjBP5R3M9EfVAjIYiw== X-Google-Smtp-Source: ABdhPJyq73kf+KpUuM9wTZCEJ8GlDuZb8DugLPNVJAXiCHPSjK5bJt4ippgXkIZxCRZ8JN1rKeHrvWuB33jSajK1+q8= X-Received: by 2002:a05:6402:a5b:: with SMTP id bt27mr6684201edb.222.1610644975588; Thu, 14 Jan 2021 09:22:55 -0800 (PST) MIME-Version: 1.0 References: <20210108222251.14391-1-tony.luck@intel.com> <20210111214452.1826-1-tony.luck@intel.com> In-Reply-To: <20210111214452.1826-1-tony.luck@intel.com> From: Andy Lutomirski Date: Thu, 14 Jan 2021 09:22:44 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 0/3] Fix infinite machine check loop in futex_wait_setup() To: Tony Luck 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" 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 Mon, Jan 11, 2021 at 1:45 PM Tony Luck wrote: > > Linux can now recover from machine checks where kernel code is > doing get_user() to access application memory. But there isn't > a way to distinguish whether get_user() failed because of a page > fault or a machine check. > > Thus there is a problem if any kernel code thinks it can retry > an access after doing something that would fix the page fault. > > One such example (I'm sure there are more) is in futex_wait_setup() > where an attempt to read the futex with page faults disabled. Then > a retry (after dropping a lock so page faults are safe): > > > ret = get_futex_value_locked(&uval, uaddr); > > if (ret) { > queue_unlock(*hb); > > ret = get_user(uval, uaddr); > > It would be good to avoid deliberately taking a second machine > check (especially as the recovery code does really bad things > and ends up in an infinite loop!). > > V2 (thanks to feedback from PeterZ) fixes this by changing get_user() to > return -ENXIO ("No such device or address") for the case where a machine > check occurred. Peter left it open which error code to use (suggesting > "-EMEMERR or whatever name we come up with"). I think the existing ENXIO > error code seems appropriate (the address being accessed has effectively > gone away). But I don't have a strong attachment if anyone thinks we > need a new code. > > Callers can check for ENXIO in paths where the access would be > retried so they can avoid a second machine check. > I don't love this -- I'm concerned that there will be some code path that expects a failing get_user() to return -EFAULT, not -ENXIO. Also, get_user() *can* return -EFAULT when it hits bad memory even with your patch if the recovery code manages to yank the PTE before get_user(). So I tend to think that the machine check code should arrange to survive some reasonable number of duplicate machine checks.