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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8AB9EEB64DC for ; Wed, 19 Jul 2023 00:00:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1BCE328001E; Tue, 18 Jul 2023 20:00:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 16DAC8D0012; Tue, 18 Jul 2023 20:00:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 034CD28001E; Tue, 18 Jul 2023 19:59:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id E86F68D0012 for ; Tue, 18 Jul 2023 19:59:59 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id B39C3160473 for ; Tue, 18 Jul 2023 23:59:59 +0000 (UTC) X-FDA: 81026403318.29.ADAA4A5 Received: from out-9.mta1.migadu.com (out-9.mta1.migadu.com [95.215.58.9]) by imf27.hostedemail.com (Postfix) with ESMTP id B694040004 for ; Tue, 18 Jul 2023 23:59:57 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=WYnZ4pp9; spf=pass (imf27.hostedemail.com: domain of naoya.horiguchi@linux.dev designates 95.215.58.9 as permitted sender) smtp.mailfrom=naoya.horiguchi@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1689724798; h=from:from:sender: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:dkim-signature; bh=MpJgs9wRGslX7B0v5r1djRNwrOTPSth9rMMf+bQv7bw=; b=P3Qr8pFuGYPwl9dNIEwbh7ghQs99nufLUdKP0K0IRFEJaWkfcy1PxE1eJmEwXexTMtPFt3 hLgYVbCA9mtuQECnbpJO92ZGv+erNu1fJum4sovQW/6NbqcGGIBg9rx3bocYL9eDCzz9tH NYi115D9pwpIevimLw8sQGMQ2X9Ms9M= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1689724798; a=rsa-sha256; cv=none; b=DxHzZY/9vK4xK34Px8+I71JYee3PY64IWSO/ddFrdGd4004hbVlI53F5wXCIaFU1EwZrrG /PNvn8Bn1AvNTT07AcPDxgLCQz5qtnJF2n15VfRkWu2X5ugSvztbyJ7IxJ8L0pctIqjI6K 4E0MYHWIaM7vVpcIOIlfw+zojWQ2tZI= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=WYnZ4pp9; spf=pass (imf27.hostedemail.com: domain of naoya.horiguchi@linux.dev designates 95.215.58.9 as permitted sender) smtp.mailfrom=naoya.horiguchi@linux.dev; dmarc=pass (policy=none) header.from=linux.dev Date: Wed, 19 Jul 2023 08:59:46 +0900 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1689724794; 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: in-reply-to:in-reply-to:references:references; bh=MpJgs9wRGslX7B0v5r1djRNwrOTPSth9rMMf+bQv7bw=; b=WYnZ4pp9slmQ2hwQev8HbcppJxGxief9n5Va5HFZ1X1tR64d3tufyCKwlA6RML4tADBRvB B+f+tEGKcFEZzN1utrRUo0hvMhShxz/vE/k9e9lpGORIXNVD/djPI8y3fYbzt2ltu3RiOL +k/JLqwpVnJErwKnw/et3BFkM+7iBgA= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Naoya Horiguchi To: Sidhartha Kumar Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org, willy@infradead.org, linmiaohe@huawei.com, naoya.horiguchi@nec.com, stable@vger.kernel.org Subject: Re: [PATCH] mm/memory-failure: fix hardware poison check in unpoison_memory() Message-ID: <20230718235946.GA1106729@ik1-406-35019.vs.sakura.ne.jp> References: <20230717181812.167757-1-sidhartha.kumar@oracle.com> <20230718001409.GA751192@ik1-406-35019.vs.sakura.ne.jp> <20230718003956.GA762147@ik1-406-35019.vs.sakura.ne.jp> <6736667f-6456-34b5-1d1f-47219e499001@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <6736667f-6456-34b5-1d1f-47219e499001@oracle.com> X-Migadu-Flow: FLOW_OUT X-Rspamd-Queue-Id: B694040004 X-Rspam-User: X-Stat-Signature: bywetzn68zd754p4t1j7htnbhdzru7p1 X-Rspamd-Server: rspam03 X-HE-Tag: 1689724797-617143 X-HE-Meta: U2FsdGVkX19GgnwNmPUHF21xeQ6+mDkv2ziB3rYOb3Cb64GQvMBlflQMjroTzF7usvXzDWilENDd3iB2JCKwAQbI+GkofmVlv9q38U90zDRCCCJftJv1d7rgsa5xwNj1R+Qak2NTryBskJyKS9vEG4B6SoBBG+zMRsywlj2LwIU3qWtPQr1HMa9ne6AfkU63rwKW4CkAD7cSRDJEWpD9t+jGy+oUhQZqQ0oRl94Z2FlQpivBg+Q/hCsB6iisXl12nweMYIlvaYQoyOefxdCqrORKtsKl0oF3rHDk/igd2L+nTYMzL0zH7Grh2B5ICXoh2DJ0eg6xB4t7CNMokmfXDipekNbjrZ8npqV3VldFyKENU3cZcmrRZEL9bR63ZtNVqHsWPNi89QjCzS/DzPJkSaVa72fRxhM2uYP4y2HbOhOxc9VOUHwykWuXnspl7cWsK77cTIRa6/anqrAbQKRr932fTVMcqZ7bjqWt8X7UfE766PSOu7AkzZnBu9tkr/agparM6MP/pDVzU2RUFYlxHWV0GxgBv6KDaCtn22dii7aZI1wH7QRdKcLTVxuwIFTkM8HqDTEr/hRAWJq80OH+4t5F+9VStgpuZ/Bdwc1My0AOTHFfmkFjhDETMWEEFvlu818ZaxYHEh6qOIN5cAQLirEIjuwRe+4muup4yvlY+lXLe7fqQJFT5KBfxQ2yO38xdNLsEOAOk7ZI+4R+sBq8be9moMtlVQztxzfgQDVH8VpPGddLBr3dNH0XM5Yfsgrt5PD7uoaxSfYQg1rDuK2eKjwXkP5410kIp2rx6fIjd/uHyBf4eDrimdr8lVUtFP9O7e/7kQjyNmLngGbBFP7fdGG0YOvi8tIE0rpgMhKjCCh7UL4zzyQfivdQafZL086AUaHYS7EaZNe2xbvmDRfWTWtzIriDGD8jY5Tq+RiY6kyMepjem6MQXLbGtBPvxC7+3Z8XBOD+XEaM0qIZu3z xwXyT824 y6bEDqmQB99Smo6zpQVeosScvHbQdATzENGovWEtsDNnBKxTu6OlC5+KygkSGPVj+TS6BUe9qZ4OROTCI8+kaPnpgYa5wNcbXKXJC4bnmoroYdzk1NEyryl450tVxcAJuhA4n82kNUwkF26UXi05PPnDd+UmQPu50PMBFtnXXEeHWGlSRQPTBge6G07PEGe2Ad9ju+P2Ml4urdIMLOnHNGtMqAFbH14Uj1VxdE9V5pOZ7F1E= 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 Tue, Jul 18, 2023 at 07:30:23AM -0700, Sidhartha Kumar wrote: > On 7/17/23 5:39 PM, Naoya Horiguchi wrote: > > On Tue, Jul 18, 2023 at 09:14:09AM +0900, Naoya Horiguchi wrote: > > > On Mon, Jul 17, 2023 at 11:18:12AM -0700, Sidhartha Kumar wrote: > > > > It was pointed out[1] that using folio_test_hwpoison() is wrong > > > > as we need to check the indiviual page that has poison. > > > > folio_test_hwpoison() only checks the head page so go back to using > > > > PageHWPoison(). > > > > > > > > Reported-by: Matthew Wilcox (Oracle) > > > > Fixes: a6fddef49eef ("mm/memory-failure: convert unpoison_memory() to folios") > > > > Cc: stable@vger.kernel.org #v6.4 > > > > Signed-off-by: Sidhartha Kumar > > > > > > > > [1]: https://lore.kernel.org/lkml/ZLIbZygG7LqSI9xe@casper.infradead.org/ > > > > --- > > > > mm/memory-failure.c | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > diff --git a/mm/memory-failure.c b/mm/memory-failure.c > > > > index 02b1d8f104d51..a114c8c3039cd 100644 > > > > --- a/mm/memory-failure.c > > > > +++ b/mm/memory-failure.c > > > > @@ -2523,7 +2523,7 @@ int unpoison_memory(unsigned long pfn) > > > > goto unlock_mutex; > > > > } > > > > - if (!folio_test_hwpoison(folio)) { > > > > + if (!PageHWPoison(p)) { > > > > > > > > > I don't think this works for hwpoisoned hugetlb pages that have PageHWPoison > > > set on the head page, rather than on the raw subpage. In the case of > > > hwpoisoned thps, PageHWPoison is set on the raw subpage, not on the head > > > pages. (I believe this is not detected because no one considers the > > > scenario of unpoisoning hwpoisoned thps, which is a rare case). Perhaps the > > > function is_page_hwpoison() would be useful for this purpose? > > > > Sorry, I was wrong. Checking PageHWPoison() is fine because the users of > > unpoison should know where the PageHWPoison is set via /proc/kpageflags. > > So this patch is OK to me after comments from other reviewers are resolved. > > > > Hi Naoya, > > While taking a closer at the patch, later in unpoison_memory() there is > also: > > - ret = TestClearPageHWPoison(page) ? 0 : -EBUSY; > + ret = folio_test_clear_hwpoison(folio) ? 0 : -EBUSY; > > I thought this folio conversion would be safe because page is the result of > a compound_head() call but I'm wondering if the same issue exists here and > we should be calling TestClearPageHWPoison() on the specific subpage by > doing TestClearPageHWPoison(p). In this case (get_hwpoison_page returns 0), the target of unpoison_memory was buddy page or free huge page, so there seems not any realistic problem. But putting back to TestClearPageHWPoison() looks consistent, so I'm fine with it. Thanks, Naoya Horiguchi