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=-11.5 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham 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 8D4EDC43461 for ; Fri, 4 Sep 2020 11:40:59 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 42AD4208CA for ; Fri, 4 Sep 2020 11:40:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 42AD4208CA Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id D5C6B900007; Fri, 4 Sep 2020 07:40:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D0D8A900003; Fri, 4 Sep 2020 07:40:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C496C900007; Fri, 4 Sep 2020 07:40:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0118.hostedemail.com [216.40.44.118]) by kanga.kvack.org (Postfix) with ESMTP id AE254900003 for ; Fri, 4 Sep 2020 07:40:58 -0400 (EDT) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 78D91824556B for ; Fri, 4 Sep 2020 11:40:58 +0000 (UTC) X-FDA: 77225187396.16.place59_5210612270b1 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin16.hostedemail.com (Postfix) with ESMTP id 3BCE7100E690C for ; Fri, 4 Sep 2020 11:40:58 +0000 (UTC) X-HE-Tag: place59_5210612270b1 X-Filterd-Recvd-Size: 7815 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf01.hostedemail.com (Postfix) with ESMTP for ; Fri, 4 Sep 2020 11:40:57 +0000 (UTC) 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 1E590B7FC; Fri, 4 Sep 2020 11:40:57 +0000 (UTC) Date: Fri, 4 Sep 2020 13:40:52 +0200 From: Oscar Salvador To: HORIGUCHI =?utf-8?B?TkFPWUEo5aCA5Y+j44CA55u05LmfKQ==?= Cc: "akpm@linux-foundation.org" , "mhocko@kernel.org" , "tony.luck@intel.com" , "cai@lca.pw" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" Subject: Re: [PATCH 1/4] mm,hwpoison: Take free pages off the buddy freelists Message-ID: <20200904114043.GA4037@linux> References: <20200902094510.10727-1-osalvador@suse.de> <20200902094510.10727-2-osalvador@suse.de> <20200904020205.GA32236@hori.linux.bs1.fc.nec.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200904020205.GA32236@hori.linux.bs1.fc.nec.co.jp> User-Agent: Mutt/1.10.1 (2018-07-13) X-Rspamd-Queue-Id: 3BCE7100E690C X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam05 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 Fri, Sep 04, 2020 at 02:02:05AM +0000, HORIGUCHI NAOYA(=E5=A0=80=E5=8F= =A3 =E7=9B=B4=E4=B9=9F) wrote: > On Wed, Sep 02, 2020 at 11:45:07AM +0200, Oscar Salvador wrote: > > The crux of the matter is that historically we left poisoned pages > > in the buddy system because we have some checks in place when > > allocating a page that a gatekeeper for poisoned pages. > > Unfortunately, we do have other users (e.g: compaction [1]) that scan > > buddy freelists and try to get a page from there without checking > > whether the page is HWPoison. > >=20 > > As I stated already, I think it is fundamentally wrong to keep > > HWPoison pages within the buddy systems, checks in place or not. > >=20 > > Let us fix this we same way we did for soft_offline [2], and take > > the page off the buddy freelist, so it is completely unreachable. > >=20 > > Note that this is fairly simple to trigger, as we only need > > to poison free buddy pages (madvise MADV_HWPOISON) and then we need > > to run some sort of memory stress system. > >=20 > > Just for a matter of reference, I put a dump_page in compaction_alloc > > to trigger for HWPoison patches: > >=20 > > kernel: page:0000000012b2982b refcount:1 mapcount:0 mapping:000000000= 0000000 index:0x1 pfn:0x1d5db > > kernel: flags: 0xfffffc0800000(hwpoison) > > kernel: raw: 000fffffc0800000 ffffea00007573c8 ffffc90000857de0 00000= 00000000000 > > kernel: raw: 0000000000000001 0000000000000000 00000001ffffffff 00000= 00000000000 > > kernel: page dumped because: compaction_alloc > >=20 > > kernel: CPU: 4 PID: 123 Comm: kcompactd0 Tainted: G E = 5.9.0-rc2-mm1-1-default+ #5 > > kernel: Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS r= el-1.10.2-0-g5f4c7b1-prebuilt.qemu-project.org 04/01/2014 > > kernel: Call Trace: > > kernel: dump_stack+0x6d/0x8b > > kernel: compaction_alloc+0xb2/0xc0 > > kernel: migrate_pages+0x2a6/0x12a0 > > kernel: ? isolate_freepages+0xc80/0xc80 > > kernel: ? __ClearPageMovable+0xb0/0xb0 > > kernel: compact_zone+0x5eb/0x11c0 > > kernel: ? finish_task_switch+0x74/0x300 > > kernel: ? lock_timer_base+0xa8/0x170 > > kernel: proactive_compact_node+0x89/0xf0 > > kernel: ? kcompactd+0x2d0/0x3a0 > > kernel: kcompactd+0x2d0/0x3a0 > > kernel: ? finish_wait+0x80/0x80 > > kernel: ? kcompactd_do_work+0x350/0x350 > > kernel: kthread+0x118/0x130 > > kernel: ? kthread_associate_blkcg+0xa0/0xa0 > > kernel: ret_from_fork+0x22/0x30 >=20 > Thanks for spotting this. >=20 > > After that, if e.g: someone faults in the page, that someone will get= killed > > unexpectedly. > >=20 > > [1] https://lore.kernel.org/linux-mm/20190826104144.GA7849@linux/T/#u > > [2] https://patchwork.kernel.org/patch/11694847/ > >=20 > > Signed-off-by: Oscar Salvador > > --- > > mm/memory-failure.c | 15 +++++++++++++-- > > 1 file changed, 13 insertions(+), 2 deletions(-) > >=20 > > diff --git a/mm/memory-failure.c b/mm/memory-failure.c > > index 696505f56910..d349dcb45056 100644 > > --- a/mm/memory-failure.c > > +++ b/mm/memory-failure.c > > @@ -1325,6 +1325,7 @@ int memory_failure(unsigned long pfn, int flags= ) > > struct dev_pagemap *pgmap; > > int res; > > unsigned long page_flags; > > + bool retry =3D true; > > =20 > > if (!sysctl_memory_failure_recovery) > > panic("Memory failure on page %lx", pfn); > > @@ -1364,10 +1365,20 @@ int memory_failure(unsigned long pfn, int fla= gs) > > * In fact it's dangerous to directly bump up page count from 0, > > * that may make page_ref_freeze()/page_ref_unfreeze() mismatch. > > */ > > +try_again: > > if (!(flags & MF_COUNT_INCREASED) && !get_hwpoison_page(p)) { > > if (is_free_buddy_page(p)) { > > - action_result(pfn, MF_MSG_BUDDY, MF_DELAYED); > > - return 0; > > + if (take_page_off_buddy(p)) { > > + action_result(pfn, MF_MSG_BUDDY, MF_DELAYED); > > + return 0; > > + } else { > > + /* We lost the race, try again */ > > + if (retry) { > > + retry =3D false; > > + goto try_again; > > + } >=20 > You might need add calling action_result() here. Yeah, I figured we would need something like: action_result(pfn, MF_MSG_BUDDY_2ND, MF_FAILED) ? Although checking other parts of the code, MF_IGNORED can suit here as we= ll, and it is probably better. > And the following block also handles buddy pages, so you could also cal= l > take_page_off_buddy() here? >=20 > /* > * We ignore non-LRU pages for good reasons. > * - PG_locked is only well defined for LRU pages and a few oth= ers > * - to avoid races with __SetPageLocked() > * - to avoid races with __SetPageSlab*() (and more non-atomic = ops) > * The check (unnecessarily) ignores LRU pages being isolated a= nd > * walked by the page reclaim code, however that's not a big lo= ss. > */ > shake_page(p, 0); > /* shake_page could have turned it free. */ > if (!PageLRU(p) && is_free_buddy_page(p)) { > if (flags & MF_COUNT_INCREASED) > action_result(pfn, MF_MSG_BUDDY, MF_DELAYED); > else > action_result(pfn, MF_MSG_BUDDY_2ND, MF_DELAYED= ); > return 0; > } >=20 > Or if get_hwpoison_page() handles retry inside it as will be done in pa= tch 3/4, > we don't need this block any more? I __think__ we do not need the following anymore: if (!PageLRU(p) && is_free_buddy_page(p)) { if (flags & MF_COUNT_INCREASED) action_result(pfn, MF_MSG_BUDDY, MF_DELAYED); else action_result(pfn, MF_MSG_BUDDY_2ND, MF_DELAYED)= ; return 0; } We have this block because shake_page() (among other things) sends pcp-pa= ges back to the buddy freelists, so we could have the chance to handle the pa= ge. Since we will be doing that in get_hwpoison_page, and such scenario shoul= d have been handled in the block from above, I think it is safe to skip tha= t block. But I think that the skape_page() has to stay as it flushes pages from pa= gevecs to their respective LRU lists, otherwise we could do the wrong thing in: if (!PageTransTail(p) && !PageLRU(p)) goto identify_page_state; So, I will send V2 with a 5th patch cleaning that up as I do not want to = get it convulated with the fix itself. thanks Naoya --=20 Oscar Salvador SUSE L3