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,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 E9260C433C1 for ; Wed, 31 Mar 2021 10:56:46 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6340361996 for ; Wed, 31 Mar 2021 10:56:45 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6340361996 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 CEFA46B007E; Wed, 31 Mar 2021 06:56:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C9FBA6B0081; Wed, 31 Mar 2021 06:56:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B19946B0082; Wed, 31 Mar 2021 06:56:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 947EB6B007E for ; Wed, 31 Mar 2021 06:56:44 -0400 (EDT) Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 4468E1DE1 for ; Wed, 31 Mar 2021 10:56:44 +0000 (UTC) X-FDA: 77979866328.09.2E974EE Received: from mail.kingsoft.com (unknown [114.255.44.146]) by imf03.hostedemail.com (Postfix) with ESMTP id 772A7C0007C6 for ; Wed, 31 Mar 2021 10:56:40 +0000 (UTC) X-AuditID: 0a580155-f55ff70000015057-86-60645566c9eb 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-2-NODE-85) with SMTP id FF.F3.20567.66554606; Wed, 31 Mar 2021 18:56:38 +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; Wed, 31 Mar 2021 18:56:38 +0800 Date: Wed, 31 Mar 2021 18:56:37 +0800 From: Aili Yao To: Oscar Salvador , "HORIGUCHI =?UTF-8?B?TkFPWUE=?=( =?UTF-8?B?5aCA5Y+j44CA55u05Lmf?=)" , "david@redhat.com" CC: "tony.luck@intel.com" , "akpm@linux-foundation.org" , "bp@alien8.de" , "tglx@linutronix.de" , "mingo@redhat.com" , "hpa@zytor.com" , "x86@kernel.org" , "inux-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: <20210331185637.76f863e2@alex-virtual-machine> In-Reply-To: <20210225113930.GA7227@localhost.localdomain> 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> 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="UTF-8" Content-Transfer-Encoding: quoted-printable 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+NgFprLIsWRmVeSWpSXmKPExsXCFcHor5sWmpJg8KxL2WLO+jVsFp83/GOz +Lr+F7PFtI3iFrcPrGG0uLxrDpvFvTX/WS0uHVjAZHGx8QCjxZlpRRabN01ltnhz4R6LxY8N j1kdeD2+t/axeCze85LJY9OqTjaPTZ8msXu8O3eO3ePEjN8sHi+ubmTxeL/vKpvH5tPVHp83 yXmcaPnCGsAdxWWTkpqTWZZapG+XwJUxu+EXU8FKvoqZV9cwNTAu4u5i5OSQEDCRePz3DSOI LSQwnUmi9ZFsFyMXkP2KUWLP2152kASLgKrEjYdtYDYbkL3r3ixWkCIRgQ2MEh9fTmMEcZgF ZrJINO5pYQKpEhbwkvhyfy3YWF4BK4mjuz+CxTmB7FXrp7NCrPjMKDFzQR8bSIJfQEyi98p/ Joib7CXatiyCahaUODnzCQuIzSygKdG6/Tc7hK0tsWzha2aIuxUlDi/5xQ7RqyRxpHsGG4Qd K9F04BbbBEbhWUhGzUIyahaSUQsYmVcxshTnphttYoTEYOgOxhlNH/UOMTJxMB5ilOBgVhLh FT6QmCDEm5JYWZValB9fVJqTWnyIUZqDRUmc9/uDpAQhgfTEktTs1NSC1CKYLBMHp1QDk/Cd cO+p56Y4R8w+8uauOueqTaGv4zxKpm58LpN5KYfD9dGe02WTbbcncvbsrd29PW3NioJ/36c7 1gmvaK/zF00udKi4ssh9TZ5Hn8Yc8x1z172ePH2v7IIm/Zxb7NtvVgpw6bx/3RM5vZllWf6h puD7DPvk/v799c189mO9uObXcrNf1BbucM3qSa1t/eH4eeGqs4+ZHyezMZ6aG/MnbufcECON D/9jOO+0PJVvU8hY1F/S+pWniu1QsqL+vv3Vv3rvrNGIupTzKbgo8k5e4dHNG2e93+hkuaBi yo3PK1ZkVK9ZyS24c/fuxcr6Jy2iDua+aou687rfesWz2rgf3y+GL8yuFRT0e6l+k31rjakS S3FGoqEWc1FxIgBKt0PeMAMAAA== X-Rspamd-Queue-Id: 772A7C0007C6 X-Stat-Signature: 6x1xdecuz6io6tfs5d4ct1eoytfsxax5 X-Rspamd-Server: rspam02 Received-SPF: none (kingsoft.com>: No applicable sender policy available) receiver=imf03; identity=mailfrom; envelope-from=""; helo=mail.kingsoft.com; client-ip=114.255.44.146 X-HE-DKIM-Result: none/none X-HE-Tag: 1617188200-673860 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000008, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, 25 Feb 2021 12:39:30 +0100 Oscar Salvador wrote: > On Thu, Feb 25, 2021 at 11:28:18AM +0000, HORIGUCHI NAOYA(=E5=A0=80=E5=8F= =A3 =E7=9B=B4=E4=B9=9F) wrote: > > Hi Aili, > >=20 > > I agree that this set_mce_nospec() is not expected to be called for > > "already hwpoisoned" page because in the reported case the error > > page is already contained and no need to resort changing cache mode. =20 >=20 > Out of curiosity, what is the current behavour now? > Say we have an ongoing MCE which has marked the page as HWPoison but > memory_failure did not take any action on the page yet. > And then, we have another MCE, which ends up there. > set_mce_nospec might clear _PAGE_PRESENT bit. >=20 > Does that have any impact on the first MCE? >=20 > > It seems to me that memory_failure() does not return MF_XXX. But yes, > > returning some positive value for the reported case could be a solution= . =20 >=20 > No, you are right. I somehow managed to confuse myself. > I see now that MF_XXX return codes are filtered out in page_action. >=20 > > We could use some negative value (error code) to report the reported ca= se, > > then as you mentioned above, some callers need change to handle the > > new case, and the same is true if you use some positive value. > > My preference is -EHWPOISON, but other options are fine if justified we= ll. =20 >=20 > -EHWPOISON seems like a good fit. >=20 Hi Oscar, david: Long away fron this topic, but i noticed today I made a stupid mistake that= EHWPOISON is already been declared, so we should better return EHWPOISON for this case. Really sorry for this! As the patch is still under review, I will post a new version for this, if = I change this, may I add your review tag here please? --=20 Thanks! Aili Yao