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=-4.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,HK_RANDOM_FROM,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_2 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 EF55BC433E0 for ; Wed, 3 Mar 2021 10:25:42 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6319A601FF for ; Wed, 3 Mar 2021 10:25:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6319A601FF 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 E39608D0154; Wed, 3 Mar 2021 05:25:35 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E10498D0135; Wed, 3 Mar 2021 05:25:35 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C89968D0154; Wed, 3 Mar 2021 05:25:35 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0130.hostedemail.com [216.40.44.130]) by kanga.kvack.org (Postfix) with ESMTP id AFA548D0135 for ; Wed, 3 Mar 2021 05:25:35 -0500 (EST) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 71F72180D0E8C for ; Wed, 3 Mar 2021 10:25:35 +0000 (UTC) X-FDA: 77878181430.16.C723DB6 Received: from mail.kingsoft.com (mail.kingsoft.com [114.255.44.145]) by imf21.hostedemail.com (Postfix) with ESMTP id 6AC98E0011E3 for ; Wed, 3 Mar 2021 10:25:29 +0000 (UTC) X-AuditID: 0a580157-f39ff7000005df43-14-603f44bd783d Received: from mail.kingsoft.com (localhost [10.88.1.32]) (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 B2.CB.57155.DB44F306; Wed, 3 Mar 2021 16:11:41 +0800 (HKT) Received: from alex-virtual-machine (172.16.253.254) by KSBJMAIL2.kingsoft.cn (10.88.1.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Wed, 3 Mar 2021 16:39:12 +0800 Date: Wed, 3 Mar 2021 16:39:12 +0800 From: Aili Yao To: "Luck, Tony" CC: "HORIGUCHI =?UTF-8?B?TkFPWUE=?=(=?UTF-8?B?5aCA5Y+j44CA55u05Lmf?=)" , Oscar Salvador , "david@redhat.com" , "akpm@linux-foundation.org" , "bp@alien8.de" , "tglx@linutronix.de" , "mingo@redhat.com" , "hpa@zytor.com" , "x86@kernel.org" , "linux-edac@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "yangfeng1@kingsoft.com" , Subject: Re: [PATCH] mm,hwpoison: return -EBUSY when page already poisoned Message-ID: <20210303163912.3d508e0f@alex-virtual-machine> In-Reply-To: <20210303115710.2e9f8e23@alex-virtual-machine> References: <20210224151619.67c29731@alex-virtual-machine> <20210224103105.GA16368@linux> <20210225114329.4e1a41c6@alex-virtual-machine> <20210225112818.GA10141@hori.linux.bs1.fc.nec.co.jp> <20210225113930.GA7227@localhost.localdomain> <20210225123806.GA15006@hori.linux.bs1.fc.nec.co.jp> <20210225181542.GA178925@agluck-desk2.amr.corp.intel.com> <20210226021907.GA27861@hori.linux.bs1.fc.nec.co.jp> <20210226105915.6cf7d2b8@alex-virtual-machine> <20210303033953.GA205389@agluck-desk2.amr.corp.intel.com> <20210303115710.2e9f8e23@alex-virtual-machine> Organization: kingsoft X-Mailer: Claws Mail 3.17.5 (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 KSBJMAIL2.kingsoft.cn (10.88.1.32) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFIsWRmVeSWpSXmKPExsXCFcGooLvXxT7BYHaLkcWc9WvYLD5v+Mdm 8XX9L2aLaRvFLS6camCyuLxrDpvFvTX/WS0uHVjAZHGx8QCjxZlpRRabN01ltnhz4R6LxY8N j1kdeD2+t/axeCze85LJY9OqTjaPTZ8msXu8O3eO3ePEjN8sHi+ubmTxeL/vKpvH5tPVHp83 yXmcaPnCGsAdxWWTkpqTWZZapG+XwJXxvHMte8Et8YojX34wNjCuFupi5OSQEDCReDplFmMX IxeHkMB0Jokl0zcxgiSEBF4ySmzf5g1iswioSFyZ+5ANxGYTUJXYdW8WK4gtIqAmcWnxA2aQ ZmaB2awSpyafZQZJCAt4SXy5vxZsEK+AlcSDN91MXYwcHJwC1hLTDvpAzN/NInG7tQbE5hcQ k+i98p8J4iB7ibYti6BaBSVOznzCAmIzC+hInFh1jBnClpfY/nYOM8QcRYnDS36xQ/QqSRzp nsEGYcdKLJv3inUCo/AsJKNmIRk1C8moBYzMqxhZinPTDTcxQqIvfAfjvKaPeocYmTgYDzFK cDArifCKv7RNEOJNSaysSi3Kjy8qzUktPsQozcGiJM7b4mSfICSQnliSmp2aWpBaBJNl4uCU amBqfTJD8vP2G72bu4LDN6fcK1y8O3rm3OTzvDd22qX+4J78QuEQ8664Jy9uLnv9yn7D46LA nbN4NaXiA05veBWW1jq7Wu2DBkcH14LV0tfY3gXoNj+uD+Di3D6nuofzBE/S5RbzNa7b7si9 fP3Nx+pFSO5dKYeu+umBL/d+PCh5cItOPFvdl997BcK+Pk+x/bDT4q+S9Lrtu2O26fvvfr92 u61YN0PPRq5rUsqTDtvJTbR4rpa16M1+sc27vfZ/OMnP/utq8J/2bVu/BbdFxU6a5TObRSjq kY49x4cw3hlxIZOlSza90Jwad9agfsfkUwt9SuZNXVg5T2v7IY53j22rdv3a//t9ot6P5hsZ 0pXn85VYijMSDbWYi4oTAQ4ONl0tAwAA X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 6AC98E0011E3 X-Stat-Signature: 8d9n5qz43uicbigidwff4quddccwwijy Received-SPF: none (kingsoft.com>: No applicable sender policy available) receiver=imf21; identity=mailfrom; envelope-from=""; helo=mail.kingsoft.com; client-ip=114.255.44.145 X-HE-DKIM-Result: none/none X-HE-Tag: 1614767129-366158 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: Hi tony: > On Tue, 2 Mar 2021 19:39:53 -0800 > "Luck, Tony" wrote: > > > On Fri, Feb 26, 2021 at 10:59:15AM +0800, Aili Yao wrote: > > > Hi naoya, tony: > > > > > > > > > > Idea for what we should do next ... Now that x86 is calling memory_failure() > > > > > from user context ... maybe parallel calls for the same page should > > > > > be blocked until the first caller completes so we can: > > > > > a) know that pages are unmapped (if that happens) > > > > > b) all get the same success/fail status > > > > > > > > One memory_failure() call changes the target page's status and > > > > affects all mappings to all affected processes, so I think that > > > > (ideally) we don't have to block other threads (letting them > > > > early return seems fine). Sometimes memory_failure() fails, > > > > but even in such case, PG_hwpoison is set on the page and other > > > > threads properly get SIGBUSs with this patch, so I think that > > > > we can avoid the worst scenario (like system stall by MCE loop). > > > > > > > I agree with naoya's point, if we block for this issue, Does this change the result > > > that the process should be killed? Or is there something other still need to be considered? > > > > Ok ... no blocking ... I do think about blocking method and the error address issue with sigbus,here is my opinion, maybe helpful: For blocking, if we block here, there are some undefine work i think should be done. As we don't know the process B triggering this error again is early-kill or not, so the previous memory_failure() call may not add B on kill_list, even if B is on kill_list, the error level for B is not proper set, as B should get an AR SIGBUS; So we can't just wait, We must have some logic adding the process B to kill list, and as this is an AR error another change should be done to current code, we need more logic in kill_proc or some other place. Even if all the work is done right. There is one more serious scenario though, we even don't know the current step the previous memory_failure() is on, So previous modification may not be usefull at all; When this scenario happens, what we can do? block or return ? if finally we return, an error code should be taken back; so we have to go to error process logic and a signal without right address will be sent; For error address with sigbus, i think this is not an issue resulted by the patch i post, before my patch, the issue is already there. I don't find a realizable way to get the correct address for same reason --- we don't know whether the page mapping is there or not when we got to kill_me_maybe(), in some case, we may get it, but there are a lot of parallel issue need to consider, and if failed we have to fallback to the error brach again, remaining current code may be an easy option; Any methods or patchs can solve the issue in a better way is OK to me, i want this issue fixed and in more complete way! -- Thanks! Aili Yao