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 AD688C433F5 for ; Sun, 30 Jan 2022 21:14:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 09E876B0071; Sun, 30 Jan 2022 16:14:34 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 04EA36B0073; Sun, 30 Jan 2022 16:14:34 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E7E966B0074; Sun, 30 Jan 2022 16:14:33 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0030.hostedemail.com [216.40.44.30]) by kanga.kvack.org (Postfix) with ESMTP id D891B6B0071 for ; Sun, 30 Jan 2022 16:14:33 -0500 (EST) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 8F8BC8249980 for ; Sun, 30 Jan 2022 21:14:33 +0000 (UTC) X-FDA: 79088207226.22.5CE14B6 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf23.hostedemail.com (Postfix) with ESMTP id D8270140003 for ; Sun, 30 Jan 2022 21:14:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=Y6C64rp3OckgZemaQ6wbEiWdl97OAVw+WvBx+s5/qQU=; b=Oa490mYU6J3F82zaqC7vMK1vrL c4uVvh0LgiZWlQ5mahycnGEzdTUilgtm0Zw9UYzrGiinrmqeOu5JGRr7eopzZiEixCt++LEDO+geZ EIOlVaPFaEq8InEDBJQMwKbLJINaRB7M3/2MKZsZacijgO6r6SgREtYP4fFj8SOuwCI6CsljdpT9V UtnnUQ/aHKwVk7tqUl+VJpPmk4JPPkGLfWFjypNghBfo4+KYUGIiomGkuFx5uvNKhfYGHPl5GUtAc u64IN0IEOb6WdIeZ4Uu3Nelh5zMnXa0KecGDlLXve9csBHKaNIs6V13s9WFTlnBBATbN1nTZ6LBsI wsbPkgQA==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1nEHWf-008nwA-Lc; Sun, 30 Jan 2022 21:14:21 +0000 Date: Sun, 30 Jan 2022 21:14:21 +0000 From: Matthew Wilcox To: David Rientjes Cc: Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Naoya Horiguchi Subject: Re: [PATCH] mm/hwpoison: Check the subpage, not the head page Message-ID: References: <20220130013042.1906881-1-willy@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: D8270140003 X-Stat-Signature: 8i851y5nqddz7akdpib3zgzfkjyksprr X-Rspam-User: nil Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=Oa490mYU; spf=none (imf23.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none X-HE-Tag: 1643577272-738782 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 Sun, Jan 30, 2022 at 12:58:17PM -0800, David Rientjes wrote: > On Sun, 30 Jan 2022, Matthew Wilcox (Oracle) wrote: > > > Hardware poison is tracked on a per-page basis, not on the head page. > > > > Signed-off-by: Matthew Wilcox (Oracle) > > --- > > mm/rmap.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/mm/rmap.c b/mm/rmap.c > > index 6a1e8c7f6213..09b08888120e 100644 > > --- a/mm/rmap.c > > +++ b/mm/rmap.c > > @@ -1553,7 +1553,7 @@ static bool try_to_unmap_one(struct page *page, struct vm_area_struct *vma, > > /* Update high watermark before we lower rss */ > > update_hiwater_rss(mm); > > > > - if (PageHWPoison(page) && !(flags & TTU_IGNORE_HWPOISON)) { > > + if (PageHWPoison(subpage) && !(flags & TTU_IGNORE_HWPOISON)) { > > pteval = swp_entry_to_pte(make_hwpoison_entry(subpage)); > > if (PageHuge(page)) { > > hugetlb_count_sub(compound_nr(page), mm); > > @@ -1873,7 +1873,7 @@ static bool try_to_migrate_one(struct page *page, struct vm_area_struct *vma, > > * memory are supported. > > */ > > subpage = page; > > - } else if (PageHWPoison(page)) { > > + } else if (PageHWPoison(subpage)) { > > pteval = swp_entry_to_pte(make_hwpoison_entry(subpage)); > > if (PageHuge(page)) { > > hugetlb_count_sub(compound_nr(page), mm); > > This looks correct. Correct me if I'm wrong that this is for consistency > and cleanup and that there is no bug being fixed by this, however. Oh, no, I think there's a real bug here. It's just that we're looking at an uncommon & hence rarely-tested scenario -- a memory fault in the middle of a THP (in mainline; obviously it'll be a little more common with arbitrary sized folios). I don't do HWPoison testing myself, so this was by inspection and not from testing. A scenario where things would go wrong is a memory error on a non-head-page would go unnoticed when migrating or unmapping. Contrariwise, if there's a hardware error on a head page, all the subpages get treated as poisoned, even though they shouldn't be.