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 6448BC433EF for ; Mon, 31 Jan 2022 13:24:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8449D6B008A; Mon, 31 Jan 2022 08:24:32 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7F2856B008C; Mon, 31 Jan 2022 08:24:32 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6E1E96B0092; Mon, 31 Jan 2022 08:24:32 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0253.hostedemail.com [216.40.44.253]) by kanga.kvack.org (Postfix) with ESMTP id 623246B008A for ; Mon, 31 Jan 2022 08:24:32 -0500 (EST) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 1921D98C1D for ; Mon, 31 Jan 2022 13:24:32 +0000 (UTC) X-FDA: 79090651584.28.5D07862 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf12.hostedemail.com (Postfix) with ESMTP id 4568D40005 for ; Mon, 31 Jan 2022 13:24:31 +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-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description; bh=OTKoir2+xcoumP1Iky+cUAgPj3dlbdxo9BpxQp1yt8Q=; b=aQq2lT8Hv17Vxf87P/InoA66Ph RTKgC9KXM797g48rjI1n9nUP9Efhq28xRamieYhQs0gsOvwmP/M/ie+MZl9Nr19b51ny5F7D20Q9u VUzAX5ekOyGkk1bX2dh6D7TlrjPoJSRfdTHHMcTrDA8IZfih1J5wI/ITt1phKIhslvDJwb2rjbiON AMRMSoRzVGlMuc7yvYUy/AJ1mPIoc94tBrWCa0zYHjd8a3oPQ9jFvMalcQycH3u9zuDCgummzvnJf VE/m9mnL5jjhdLgo/TzeiIjy455XvQbEEoRAmde9rn8a3ITn2qOJfl4XW/zhFzkgHVu6Py4RhzdpU lcbAaH7g==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1nEWfT-009teD-24; Mon, 31 Jan 2022 13:24:27 +0000 Date: Mon, 31 Jan 2022 13:24:27 +0000 From: Matthew Wilcox To: HORIGUCHI =?utf-8?B?TkFPWUEo5aCA5Y+j44CA55u05LmfKQ==?= Cc: David Rientjes , Andrew Morton , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] mm/hwpoison: Check the subpage, not the head page Message-ID: References: <20220130013042.1906881-1-willy@infradead.org> <20220131054432.GA856839@hori.linux.bs1.fc.nec.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20220131054432.GA856839@hori.linux.bs1.fc.nec.co.jp> Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=aQq2lT8H; spf=none (imf12.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-Rspam-User: nil X-Rspamd-Queue-Id: 4568D40005 X-Stat-Signature: egd8rjqkd6sewdyubz9378cqge7t15q7 X-Rspamd-Server: rspam12 X-HE-Tag: 1643635471-313755 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 Mon, Jan 31, 2022 at 05:44:35AM +0000, HORIGUCHI NAOYA(=E5=A0=80=E5=8F= =A3 =E7=9B=B4=E4=B9=9F) wrote: > On Sun, Jan 30, 2022 at 09:14:21PM +0000, Matthew Wilcox wrote: > > On Sun, Jan 30, 2022 at 12:58:17PM -0800, David Rientjes wrote: > > > On Sun, 30 Jan 2022, Matthew Wilcox (Oracle) wrote: > > >=20 > > > > Hardware poison is tracked on a per-page basis, not on the head p= age. > > > >=20 > > > > Signed-off-by: Matthew Wilcox (Oracle) > > > > --- > > > > mm/rmap.c | 4 ++-- > > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > >=20 > > > > 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 *p= age, struct vm_area_struct *vma, > > > > /* Update high watermark before we lower rss */ > > > > update_hiwater_rss(mm); > > > > =20 > > > > - if (PageHWPoison(page) && !(flags & TTU_IGNORE_HWPOISON)) { > > > > + if (PageHWPoison(subpage) && !(flags & TTU_IGNORE_HWPOISON)) { > > > > pteval =3D 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 =3D page; > > > > - } else if (PageHWPoison(page)) { > > > > + } else if (PageHWPoison(subpage)) { > > > > pteval =3D swp_entry_to_pte(make_hwpoison_entry(subpage)); > > > > if (PageHuge(page)) { > > > > hugetlb_count_sub(compound_nr(page), mm); > > >=20 > > > This looks correct. Correct me if I'm wrong that this is for consi= stency=20 > > > and cleanup and that there is no bug being fixed by this, however. > >=20 > > Oh, no, I think there's a real bug here. It's just that we're lookin= g > > at an uncommon & hence rarely-tested scenario -- a memory fault in th= e > > 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 unnotice= d > > when migrating or unmapping. Contrariwise, if there's a hardware err= or > > on a head page, all the subpages get treated as poisoned, even though > > they shouldn't be. >=20 > Thank you for reporting. As you point out, the current check does not > handle thp properly. The reason of checking head page here is to handl= e > hwpoisoned hugetlb (which has PG_hwpoison on the head page even if the = error > is on any of tail page). So I think that the proper fix is to add a he= lper > function to check page type (normal, thp, or hugetlb) as well as PageHW= Poison. I think this handles HugeTLB pages correctly: subpage =3D page - page_to_pfn(page) + pte_pfn(*pvmw.pte)= ; As I understand the HugeTLB code, pvmw.pte refers to the head page, not the subpage (unlike a PTE-mapped THP page, where it would refer to the precise page). But I cheerfully admit that the intricacies of the HugeTLB code are not something I'm an expert on.