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=-9.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,HK_RANDOM_FROM,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_2 autolearn=unavailable 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 81E67C433B4 for ; Thu, 8 Apr 2021 02:13:47 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 32488611C0 for ; Thu, 8 Apr 2021 02:13:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 32488611C0 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kingsoft.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 86D258D0001; Wed, 7 Apr 2021 22:13:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 81CA16B0081; Wed, 7 Apr 2021 22:13:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 696028D0001; Wed, 7 Apr 2021 22:13:43 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0146.hostedemail.com [216.40.44.146]) by kanga.kvack.org (Postfix) with ESMTP id 495286B0080 for ; Wed, 7 Apr 2021 22:13:43 -0400 (EDT) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id E8AE718022018 for ; Thu, 8 Apr 2021 02:13:42 +0000 (UTC) X-FDA: 78007578684.07.F075ED8 Received: from mail.kingsoft.com (unknown [114.255.44.146]) by imf25.hostedemail.com (Postfix) with ESMTP id D801E6000108 for ; Thu, 8 Apr 2021 02:13:38 +0000 (UTC) X-AuditID: 0a580157-e3bff7000005ef4a-b7-606e66cf2c03 Received: from mail.kingsoft.com (localhost [10.88.1.79]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail.kingsoft.com (SMG-1-NODE-87) with SMTP id 3F.7E.61258.FC66E606; Thu, 8 Apr 2021 10:13:35 +0800 (HKT) Received: from alex-virtual-machine (172.16.253.254) by KSBJMAIL4.kingsoft.cn (10.88.1.79) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Thu, 8 Apr 2021 10:13:35 +0800 Date: Thu, 8 Apr 2021 10:13:35 +0800 From: Aili Yao To: Tony Luck , Borislav Petkov CC: , , , Andy Lutomirski , "HORIGUCHI NAOYA( =?UTF-8?B?5aCA5Y+j?= =?UTF-8?B?44CA55u05Lmf?=)" , Subject: Re: [RFC 0/4] Fix machine check recovery for copy_from_user Message-ID: <20210408101335.28fd3692@alex-virtual-machine> In-Reply-To: <20210326000235.370514-1-tony.luck@intel.com> References: <20210326000235.370514-1-tony.luck@intel.com> Organization: kingsoft X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.30; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Originating-IP: [172.16.253.254] X-ClientProxiedBy: KSBJMAIL1.kingsoft.cn (10.88.1.31) To KSBJMAIL4.kingsoft.cn (10.88.1.79) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsXCFcHor3s+LS/B4FermcXnDf/YLC7vmsNm cW/Nf1aL87vWslpcbDzAaPHmwj0Wix8bHrM6sHt8b+1j8Vi85yWTx6ZVnWwemz5NYvd4cXUj i8fnTXIBbFFcNimpOZllqUX6dglcGXuvfmMp+CZQcfUqewPjf54uRk4OCQETiXsNb5i6GLk4 hASmM0m8vHwFynnJKHGxdQEzSBWLgIpEy/1JYDabgKrErnuzWEFsEQFnifmN7YwgDcwCzxgl Jvx+DVYkLOAi8aFpLlsXIwcHr4CVxM1leiAmJ5C54r8niCkkYCkx70MVSDG/gJhE75X/TCBh CQF7icfrFUHCvAKCEidnPmEBsZkFdCROrDrGDGHLS2x/OwfMFhJQlDi85Bc7xCtKEke6Z7BB 2LESTQdusU1gFJ6FZNQsJKNmIRm1gJF5FSNLcW664SZGSDyE72Cc1/RR7xAjEwfjIUYJDmYl Ed4dvdkJQrwpiZVVqUX58UWlOanFhxilOViUxHnza3IThATSE0tSs1NTC1KLYLJMHJxSDUxb JKqT9pxd2+3j62Eu4WC37UpOuY20g6HdeW7Di53dp3NN2aKjyrbevHpY9cHSrGAmQ1Wje/nM r7j31enyN/1MeF/g+lzOMp9L5P3V9wraVo+jbla9MJV/YzBZJfBisu7/Ty1lt+aVBv+aouGh 2BBjPGVR9SWh+W/aVh6sj7B18WTUnvrJ5X23wpW/5c3if649+rwylOHSLpbTljNfbGIuCGp8 +p1nds3E8/fST+5h+n9xd7dRULn7Xfu1uj3LOpmSvBi3sjz1j9sn6BrZqXZ6ymKeV2GR9h05 xlsra+VCJLMafHxfm83QelUutDXLXPGHQdLFDycLNx7e42Fx9pvlFZUFziIfa9s27rlyXYml OCPRUIu5qDgRACgUgg72AgAA X-Stat-Signature: taurpyzsuoj4sb1p4ckffaknqzzzpsxo X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: D801E6000108 Received-SPF: none (kingsoft.com>: No applicable sender policy available) receiver=imf25; identity=mailfrom; envelope-from=""; helo=mail.kingsoft.com; client-ip=114.255.44.146 X-HE-DKIM-Result: none/none X-HE-Tag: 1617848018-702991 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 Thu, 25 Mar 2021 17:02:31 -0700 Tony Luck wrote: > Maybe this is the way forward? I made some poor choices before > to treat poison consumption in the kernel when accessing user data > (get_user() or copy_from_user()) ... in particular assuming that > the right action was sending a SIGBUS to the task as if it had > synchronously accessed the poison location. > > First three patches may need to be combined (or broken up differently) > for bisectablilty. But they are presented separately here since they > touch separate parts of the problem. > > Second part is definitley incomplete. But I'd like to check that it > is the right approach before expending more brain cells in the maze > of nested macros that is lib/iov_iter.c > > Last part has been posted before. It covers the case where the kernel > takes more than one swing at reading poison data before returning to > user. > > Tony Luck (4): > x86/mce: Fix copyin code to return -EFAULT on machine check. > mce/iter: Check for copyin failure & return error up stack > mce/copyin: fix to not SIGBUS when copying from user hits poison > x86/mce: Avoid infinite loop for copy from user recovery > > arch/x86/kernel/cpu/mce/core.c | 63 +++++++++++++++++++++--------- > arch/x86/kernel/cpu/mce/severity.c | 2 - > arch/x86/lib/copy_user_64.S | 18 +++++---- > fs/iomap/buffered-io.c | 8 +++- > include/linux/sched.h | 2 +- > include/linux/uio.h | 2 +- > lib/iov_iter.c | 15 ++++++- > 7 files changed, 77 insertions(+), 33 deletions(-) > I have one scenario, may you take into account: If one copyin case occurs, write() returned by your patch, the user process may check the return values, for errors, it may exit the process, then the error page will be freed, and then the page maybe alloced to other process or to kernel itself, then code will initialize it and this will trigger one SRAO, if it's used by kernel, we may do nothing for this, and kernel may still touch it, and lead to one panic. Is this we expect? Thanks! Aili Yao