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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 94201C433B4 for ; Thu, 22 Apr 2021 17:02:35 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 154176142F for ; Thu, 22 Apr 2021 17:02:35 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 154176142F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=alien8.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 884AB6B0071; Thu, 22 Apr 2021 13:02:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 834656B0072; Thu, 22 Apr 2021 13:02:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6AE526B0073; Thu, 22 Apr 2021 13:02:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0127.hostedemail.com [216.40.44.127]) by kanga.kvack.org (Postfix) with ESMTP id 44B9C6B0071 for ; Thu, 22 Apr 2021 13:02:34 -0400 (EDT) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id ED2E834A3 for ; Thu, 22 Apr 2021 17:02:33 +0000 (UTC) X-FDA: 78060621786.08.150225F Received: from mail.skyhub.de (mail.skyhub.de [5.9.137.197]) by imf24.hostedemail.com (Postfix) with ESMTP id 7E86BA001AB1 for ; Thu, 22 Apr 2021 17:02:03 +0000 (UTC) Received: from zn.tnic (p200300ec2f0e2900329c23fffea6a903.dip0.t-ipconnect.de [IPv6:2003:ec:2f0e:2900:329c:23ff:fea6:a903]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 279641EC047F; Thu, 22 Apr 2021 19:02:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1619110921; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:in-reply-to:in-reply-to: references:references; bh=V9HbXQ0do/5kolNtrmxXCTBW4RIorF+m2CxiqXYrMkA=; b=G8wRccL+4ing5H+EGOTjGZcQWlEIEnnysR9kZJe/ZMV67xSvcItpJhGF9nmjKVglPadRcT U1sxGuTge9x5mqQcPpV6pordkU2ienB/SUMpur3xpaCxBodg9ytUOUeBdjX74ZDFEn2+uo Rh6AHTZSC+oF9EPWARes4lsWOwv18xo= Date: Thu, 22 Apr 2021 19:02:04 +0200 From: Borislav Petkov To: Naoya Horiguchi Cc: linux-mm@kvack.org, Tony Luck , Aili Yao , Andrew Morton , Oscar Salvador , David Hildenbrand , Andy Lutomirski , Naoya Horiguchi , Jue Wang , linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 2/3] mm,hwpoison: return -EHWPOISON when page already Message-ID: <20210422170204.GD7021@zn.tnic> References: <20210421005728.1994268-1-nao.horiguchi@gmail.com> <20210421005728.1994268-3-nao.horiguchi@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20210421005728.1994268-3-nao.horiguchi@gmail.com> X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 7E86BA001AB1 X-Stat-Signature: y8f3auqaz5sy4qj78ystyd4s8nkxwtpq Received-SPF: none (alien8.de>: No applicable sender policy available) receiver=imf24; identity=mailfrom; envelope-from=""; helo=mail.skyhub.de; client-ip=5.9.137.197 X-HE-DKIM-Result: invalid/invalid (public key: DNS error: SERVFAIL) X-HE-Tag: 1619110923-317115 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 Wed, Apr 21, 2021 at 09:57:27AM +0900, Naoya Horiguchi wrote: > From: Aili Yao > Subject: Re: [PATCH v3 2/3] mm,hwpoison: return -EHWPOISON when page already ... Return -EHWPOISON to denote that the page has already been poisoned" > When the page is already poisoned, another memory_failure() call in the > same page now returns 0, meaning OK. For nested memory mce handling, this > behavior may lead to one mce looping, s/mce/MCE/g > Example: For example: > 1. When LCME is enabled, and there are two processes A && B running on > different core X && Y separately, which will access one same page, then which access the same page... s/&&/and/g > the page corrupted when process A access it, a MCE will be rasied to > core X and the error process is just underway. ... and you lost me here. I don't understand what that is trying to say. Is that trying to say that when process A encounters the error, the MCE will be raised on CPU X? > 2. Then B access the page and trigger another MCE to core Y, it will also > do error process, it will see TestSetPageHWPoison be true, and 0 is > returned. That sentence needs massaging. > 3. The kill_me_maybe will check the return: > > 1244 static void kill_me_maybe(struct callback_head *cb) > 1245 { > ... > 1254 if (!memory_failure(p->mce_addr >> PAGE_SHIFT, flags) && > 1255 !(p->mce_kflags & MCE_IN_KERNEL_COPYIN)) { > 1256 set_mce_nospec(p->mce_addr >> PAGE_SHIFT, p->mce_whole_page); > 1257 sync_core(); > 1258 return; > 1259 } > ... > 1267 } No need for the line numbers. > 4. The error process for B will end, and may nothing happened if > kill-early is not set, The process B will re-excute instruction and get > into mce again and then loop happens. And also the set_mce_nospec() > here is not proper, may refer to commit fd0e786d9d09 ("x86/mm, > mm/hwpoison: Don't unconditionally unmap kernel 1:1 pages"). That needs massaging too. > For other cases which care the return value of memory_failure() should > check why they want to process a memory error which have already been > processed. This behavior seems reasonable. This whole commit message needs sanitizing. Also, looking at the next patch, you can merge this one into the next because the next one is acting on -EHWPOISON so it all belongs together in a single patch. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette