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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,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 07E15C433DB for ; Thu, 25 Feb 2021 11:39:44 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7934264F19 for ; Thu, 25 Feb 2021 11:39:43 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7934264F19 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id D73E48D0019; Thu, 25 Feb 2021 06:39:42 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D26088D0005; Thu, 25 Feb 2021 06:39:42 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C3D958D0019; Thu, 25 Feb 2021 06:39:42 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0140.hostedemail.com [216.40.44.140]) by kanga.kvack.org (Postfix) with ESMTP id AE4238D0005 for ; Thu, 25 Feb 2021 06:39:42 -0500 (EST) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 73040185044BE for ; Thu, 25 Feb 2021 11:39:42 +0000 (UTC) X-FDA: 77856595404.16.379E675 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf20.hostedemail.com (Postfix) with ESMTP id C7AEE138 for ; Thu, 25 Feb 2021 11:39:41 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 59D36AC6E; Thu, 25 Feb 2021 11:39:40 +0000 (UTC) Date: Thu, 25 Feb 2021 12:39:30 +0100 From: Oscar Salvador To: HORIGUCHI =?utf-8?B?TkFPWUEo5aCA5Y+j44CA55u05LmfKQ==?= Cc: Aili Yao , "tony.luck@intel.com" , "david@redhat.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: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20210225112818.GA10141@hori.linux.bs1.fc.nec.co.jp> X-Stat-Signature: smc4tctawij6txdmzzbat7osnyp1xzo7 X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: C7AEE138 Received-SPF: none (suse.de>: No applicable sender policy available) receiver=imf20; identity=mailfrom; envelope-from=""; helo=mx2.suse.de; client-ip=195.135.220.15 X-HE-DKIM-Result: none/none X-HE-Tag: 1614253181-568854 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 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. 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. Does that have any impact on the first MCE? > 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= . No, you are right. I somehow managed to confuse myself. I see now that MF_XXX return codes are filtered out in page_action. > 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. -EHWPOISON seems like a good fit. --=20 Oscar Salvador SUSE L3