Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp329714pxb; Thu, 25 Feb 2021 03:51:24 -0800 (PST) X-Google-Smtp-Source: ABdhPJyP1aHy0ZS5aOjPUPq5WXnxhNiqpYEpYJyj/BryRrrFFqMx375INcc3IPN5OMh95SyHHMdy X-Received: by 2002:a17:906:1cc2:: with SMTP id i2mr2386927ejh.320.1614253884550; Thu, 25 Feb 2021 03:51:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614253884; cv=none; d=google.com; s=arc-20160816; b=zzVhgs4X8yf4/1YM/8Z+C1YBB9BxrUs+o9Aw31kECzC7PxiDBEQmZjZyasifgU6TDA ytuaGdTg2psKYEs8kkaKWoU4Mc3EIx3/+J783S8a+3aOWUbArTU13cIlD8/Xrdzo4Ykr AjOk3ykjpii02IfD03YDWre1hz3BwGvb8djGDzFuVYOj/Km/MeooaMJW36RlS2U4m0C0 hZbUJZcWZmVbsbbYENJFJMSyReT0sFJpc/8PfcdjCt80zu/JA1zbAjGodaEin0mxN1EP jrs+737tB0LqklIW4TjsbehiaG0oZHQc3pzbbe6sCBN8DFIWxukXOJsUssfw2pAP5YZ1 UtiA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=U3vFD0JlaacfwD5jvKTzZnkGOFGMUZwyQUe0oojgyPo=; b=VwMA6bD/xewDCKToR5ldMv2tzxrzPjhDlcRTnAULXY8mKjVK3Oc6K/AKopYhjbUoci 2wIgiLlWd5379HZuqWmDjclU1ix3PsrFokhqGNAbSxqt/0UXgGGb/HTugORJq3OefHvJ 0fbdt45lWDfJF1IbrkWcgdCIa7RtinQ5UUXutjg8zlTc2+CrQDE57OXa9N3psWND+8eA QEVpN6VzevTUMtiZcV5hjlv3xBZVIZofm2riBD0SBezSzfuIxlgCSrxm5AZkilR7EJaP w7ENVfkcamKzrnMP61VnZSnmgfERGgSfI3Rufw+Uf36ruvpeprpET8c6NdAX2fGs64oQ Y81A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id e4si3032609edv.36.2021.02.25.03.51.01; Thu, 25 Feb 2021 03:51:24 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232642AbhBYLkX (ORCPT + 99 others); Thu, 25 Feb 2021 06:40:23 -0500 Received: from mx2.suse.de ([195.135.220.15]:55048 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231895AbhBYLkW (ORCPT ); Thu, 25 Feb 2021 06:40:22 -0500 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 Content-Transfer-Encoding: 8bit In-Reply-To: <20210225112818.GA10141@hori.linux.bs1.fc.nec.co.jp> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Feb 25, 2021 at 11:28:18AM +0000, HORIGUCHI NAOYA(堀口 直也) wrote: > Hi Aili, > > 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 case, > 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 well. -EHWPOISON seems like a good fit. -- Oscar Salvador SUSE L3