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 3F0FCC433F5 for ; Thu, 10 Mar 2022 19:32:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AE9EC8D0002; Thu, 10 Mar 2022 14:32:22 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A99398D0001; Thu, 10 Mar 2022 14:32:22 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 938FA8D0002; Thu, 10 Mar 2022 14:32:22 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0050.hostedemail.com [216.40.44.50]) by kanga.kvack.org (Postfix) with ESMTP id 847AA8D0001 for ; Thu, 10 Mar 2022 14:32:22 -0500 (EST) Received: from smtpin19.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 344069ACA3 for ; Thu, 10 Mar 2022 19:32:22 +0000 (UTC) X-FDA: 79229472924.19.27962C2 Received: from mail-pj1-f46.google.com (mail-pj1-f46.google.com [209.85.216.46]) by imf03.hostedemail.com (Postfix) with ESMTP id C272920020 for ; Thu, 10 Mar 2022 19:32:21 +0000 (UTC) Received: by mail-pj1-f46.google.com with SMTP id bx5so6151132pjb.3 for ; Thu, 10 Mar 2022 11:32:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Sr3SX+mGHTgqjkBw1Uo/W0bQ5BGSr7vLQugK0O3LT2E=; b=Xcj1FwZrk4lcSoGUxFDc0q8x0zHopLJ9GfqF9bDR9iCF9ecyA8Bey+E11iybuB+l+2 2ahfw9c+z9etE/a6rwI4LJgfiwLtRHdjCYc2jmIj0/UJKLH5/v9eChBT/juu5/XUR6u3 uQKKwUy7ap/o0OnTWQhmTmEwHwTzVNDqw/frqrea41bws+WcohYBWF5UxrNc8SIHV4n2 aNxB4f5mnxu7ZfG/btmGUHV4rKn3LBOyTfC8srd2WJ9Jq+ek68LirzA+uXlkXCd1qPGB 5Eq/FoXlrokACZ8ffNFM796MiIaUGLKxYE3FPGjdibJUsYaHehTiTNkzjEPEw55uPuUe +M7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Sr3SX+mGHTgqjkBw1Uo/W0bQ5BGSr7vLQugK0O3LT2E=; b=2Seojih8XDzqSqveTzv6DSiDZpzA0PyQZE35xPKadW6AnC5IBoNcnRbjdgJsnUpR9g 2IwKBtQLYpjZU1Xhb6SJCPhJMb1+6744wh2tMuVRvgIwKuBZ2/fqQwAlc/VOLY6QLFJM ZbEEyxzf8cV7HWhOOSy+LuRCGWanAV4Ea0WyzD5PEsDKCCMIt+uFZJXCElt+4UpUxnxZ WmkV7KrGjOC/atI9zmRjZ3CoUYf09mrSXz/afWN5mUoQjU5OiXHrsSpQ3EEbGGwD+IGB SruLm0lYYSvWQrDG/0DF+o52zZMymtJeBD5ZS1zUVOad0uCggy2sPi7gWW2MevVpn3HT YTPA== X-Gm-Message-State: AOAM531TCGuCAiYSi/FAgMd54tVSBIrK0JQx2PZzVSS+g0/51dDLG2E5 1j22q8CAVuiHJQNSSUaAse34By+5jdjxFBI+iP0= X-Google-Smtp-Source: ABdhPJxbG7VpTq0KFgDmrq4D1beszby6aE9wHDYQ1dh/4YKRcIJj1WB8jCEMa18vh3/OqWtLH0GlnM1XpCw3dBULecc= X-Received: by 2002:a17:90a:3906:b0:1bf:a0a6:d208 with SMTP id y6-20020a17090a390600b001bfa0a6d208mr13163189pjb.21.1646940740594; Thu, 10 Mar 2022 11:32:20 -0800 (PST) MIME-Version: 1.0 References: <20220228140245.24552-1-linmiaohe@huawei.com> <20220228140245.24552-5-linmiaohe@huawei.com> <20220304082804.GC3778609@hori.linux.bs1.fc.nec.co.jp> <2311bee4-cc11-93fc-6992-6c327a150e3d@huawei.com> In-Reply-To: From: Yang Shi Date: Thu, 10 Mar 2022 11:32:08 -0800 Message-ID: Subject: Re: [PATCH 4/4] mm/memory-failure.c: fix potential VM_BUG_ON_PAGE in split_huge_page_to_list To: Miaohe Lin Cc: =?UTF-8?B?SE9SSUdVQ0hJIE5BT1lBKOWggOWPoyDnm7TkuZ8p?= , "akpm@linux-foundation.org" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam10 X-Rspam-User: X-Stat-Signature: yw6h1cjpeds3jjoqbkfgc5i9dkp1mqwg Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=Xcj1FwZr; spf=pass (imf03.hostedemail.com: domain of shy828301@gmail.com designates 209.85.216.46 as permitted sender) smtp.mailfrom=shy828301@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspamd-Queue-Id: C272920020 X-HE-Tag: 1646940741-992290 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 Thu, Mar 10, 2022 at 3:46 AM Miaohe Lin wrote: > > On 2022/3/9 2:47, Yang Shi wrote: > > On Tue, Mar 8, 2022 at 4:36 AM Miaohe Lin wrote: > >> > >> On 2022/3/8 3:53, Yang Shi wrote: > >>> On Sun, Mar 6, 2022 at 11:07 PM Miaohe Lin wro= te: > >>>> > >>>> On 2022/3/4 16:28, HORIGUCHI NAOYA(=E5=A0=80=E5=8F=A3 =E7=9B=B4=E4= =B9=9F) wrote: > >>>>> On Mon, Feb 28, 2022 at 10:02:45PM +0800, Miaohe Lin wrote: > >>>>>> The huge zero page could reach here and if we ever try to split it= , the > >>>>>> VM_BUG_ON_PAGE will be triggered in split_huge_page_to_list(). Als= o the > >>>>>> non-lru compound movable pages could be taken for transhuge pages.= Skip > >>>>>> these pages by checking PageLRU because huge zero page isn't lru p= age as > >>>>>> non-lru compound movable pages. > >>>>> > >>>>> It seems that memory_failure() also fails at get_any_page() with "h= wpoison: > >>>>> unhandlable page" message. > >>>>> > >>>>> [16478.203474] page:00000000b6acdbd1 refcount:1 mapcount:0 mappin= g:0000000000000000 index:0x0 pfn:0x1810b4 > >>>>> [16478.206612] flags: 0x57ffffc0801000(reserved|hwpoison|node=3D1= |zone=3D2|lastcpupid=3D0x1fffff) > >>>>> [16478.209411] raw: 0057ffffc0801000 fffff11bc6042d08 fffff11bc60= 42d08 0000000000000000 > >>>>> [16478.211921] raw: 0000000000000000 0000000000000000 00000001fff= fffff 0000000000000000 > >>>>> [16478.214473] page dumped because: hwpoison: unhandlable page > >>>>> [16478.216386] Memory failure: 0x1810b4: recovery action for unkn= own page: Ignored > >>>>> > >>>>> We can't handle errors on huge (or normal) zero page, so the curren= t > >>>> > >>>> Sorry for confusing commit log again. I should have a coffee before = I make this patch. > >>>> Huge or normal zero page will fail at get_any_page because they're n= either HWPoisonHandlable > >>>> nor PageHuge. > >>>> > >>>>> behavior seems to me more suitable than "unsplit thp". > >>>>> > >>>>> Or if you have some producer to reach the following path with huge = zero > >>>>> page, could you share it? > >>>>> > >>>> > >>>> What I mean is that non-lru movable compound page can reach here une= xpected because __PageMovable(page) > >>>> is handleable now. So get_any_page could succeed to grab the page re= fcnt. And since it's compound page, > >>>> it will go through the split_huge_page_to_list because PageTransHuge= checks PageHead(page) which can also > >>>> be true for compound page. But this type of pages is unexpected for = split_huge_page_to_list. > >>> > >>> Can we really handle non-LRU movable pages in memory failure > >>> (uncorrectable errors)? Typically they are balloon, zsmalloc, etc. > >>> Assuming we run into a base (4K) non-LRU movable page, we could reach > >>> as far as identify_page_state(), it should not fall into any category > >>> except me_unknown. So it seems we could just simply make it > >>> unhandlable. > >> > >> There is the comment from memory_failure: > >> /* > >> * We ignore non-LRU pages for good reasons. > >> * - PG_locked is only well defined for LRU pages and a few ot= hers > >> * - to avoid races with __SetPageLocked() > >> * - to avoid races with __SetPageSlab*() (and more non-atomic= ops) > >> * The check (unnecessarily) ignores LRU pages being isolated = and > >> * walked by the page reclaim code, however that's not a big l= oss. > >> */ > >> > >> So we could not handle non-LRU movable pages. > >> > >> What do you mean is something like below? > >> > >> diff --git a/mm/memory-failure.c b/mm/memory-failure.c > >> index 5444a8ef4867..d80dbe0f20b6 100644 > >> --- a/mm/memory-failure.c > >> +++ b/mm/memory-failure.c > >> @@ -1784,6 +1784,13 @@ int memory_failure(unsigned long pfn, int flags= ) > >> } > >> } > >> > >> + if (__PageMovable(hpage)) { > >> + put_page(p); > >> + action_result(pfn, MF_MSG_MOVALBE_PAGE, MF_IGNORED); > >> + res =3D -EBUSY; > >> + goto unlock_mutex; > >> + } > >> + > >> if (PageTransHuge(hpage)) { > >> /* > >> * The flag must be set after the refcount is bumped > >> > >> > >> i.e. Simply make non-LRU movable pages unhandlable ? > > > > I think about the below code more carefully and I found that this will ma= ke > hwpoison_filter can't handle the non-LRU movable pages now. Because non-L= RU > movable pages return early now and thus can't reach the hwpoison_filter. = This > results in a inconsistent behavior with previous one. So I think the orig= in > fixup of this patch is more suitable. What do you think? I'm not familiar with hwpoison_filter(), it seems like a test helper for error injection. I don't think hwpoison_filter() is used to filter unhandlable page, for example, slab page, IIUC. So the non-LRU movable pages should be treated the same. If so, the old behavior was simply wrong. > > Thanks. > > > I'd prefer this personally. Something like the below (compile test only= ): > > > > diff --git a/mm/memory-failure.c b/mm/memory-failure.c > > index 5444a8ef4867..789e40909ade 100644 > > --- a/mm/memory-failure.c > > +++ b/mm/memory-failure.c > > @@ -1176,12 +1176,18 @@ void ClearPageHWPoisonTakenOff(struct page *pag= e) > > * does not return true for hugetlb or device memory pages, so it's as= sumed > > * to be called only in the context where we never have such pages. > > */ > > -static inline bool HWPoisonHandlable(struct page *page) > > +static inline bool HWPoisonHandlable(struct page *page, unsigned long = flags) > > { > > - return PageLRU(page) || __PageMovable(page) || is_free_buddy_page(pag= e); > > + bool movable =3D false; > > + > > + /* Soft offline could mirgate non-LRU movable pages */ > > + if ((flags & MF_SOFT_OFFLINE) && __PageMovable(page)) > > + movable =3D true; > > + > > + return movable || PageLRU(page) || is_free_buddy_page(page); > > } > > > > -static int __get_hwpoison_page(struct page *page) > > +static int __get_hwpoison_page(struct page *page, unsigned long flags) > > { > > struct page *head =3D compound_head(page); > > int ret =3D 0; > > @@ -1196,7 +1202,7 @@ static int __get_hwpoison_page(struct page *page) > > * for any unsupported type of page in order to reduce the risk of > > * unexpected races caused by taking a page refcount. > > */ > > - if (!HWPoisonHandlable(head)) > > + if (!HWPoisonHandlable(head, flags)) > > return -EBUSY; > > > > if (get_page_unless_zero(head)) { > > @@ -1221,7 +1227,7 @@ static int get_any_page(struct page *p, unsigned > > long flags) > > > > try_again: > > if (!count_increased) { > > - ret =3D __get_hwpoison_page(p); > > + ret =3D __get_hwpoison_page(p, flags); > > if (!ret) { > > if (page_count(p)) { > > /* We raced with an allocation, retry. */ > > @@ -1249,7 +1255,7 @@ static int get_any_page(struct page *p, unsigned > > long flags) > > } > > } > > > > - if (PageHuge(p) || HWPoisonHandlable(p)) { > > + if (PageHuge(p) || HWPoisonHandlable(p, flags)) { > > ret =3D 1; > > } else { > > /* > > > >> > >>> > >>> But it should be handlable for soft-offline since it could be migrate= d. > >>> > >> > >> Yes, non-LRU movable pages can be simply migrated. > >> > >> Many thanks. > >> > >>> > >>>> Does this make sense for you? Thanks Naoya. > >>>> > >>>>> Thanks, > >>>>> Naoya Horiguchi > >>>>> > >>>>>> > >>>>>> Signed-off-by: Miaohe Lin > >>>>>> --- > >>>>>> mm/memory-failure.c | 14 ++++++++++++++ > >>>>>> 1 file changed, 14 insertions(+) > >>>>>> > >>>>>> diff --git a/mm/memory-failure.c b/mm/memory-failure.c > >>>>>> index 23bfd809dc8c..ac6492e36978 100644 > >>>>>> --- a/mm/memory-failure.c > >>>>>> +++ b/mm/memory-failure.c > >>>>>> @@ -1792,6 +1792,20 @@ int memory_failure(unsigned long pfn, int f= lags) > >>>>>> } > >>>>>> > >>>>>> if (PageTransHuge(hpage)) { > >>>>>> + /* > >>>>>> + * The non-lru compound movable pages could be taken = for > >>>>>> + * transhuge pages. Also huge zero page could reach h= ere > >>>>>> + * and if we ever try to split it, the VM_BUG_ON_PAGE= will > >>>>>> + * be triggered in split_huge_page_to_list(). Skip th= ese > >>>>>> + * pages by checking PageLRU because huge zero page i= sn't > >>>>>> + * lru page as non-lru compound movable pages. > >>>>>> + */ > >>>>>> + if (!PageLRU(hpage)) { > >>>>>> + put_page(p); > >>>>>> + action_result(pfn, MF_MSG_UNSPLIT_THP, MF_IGN= ORED); > >>>>>> + res =3D -EBUSY; > >>>>>> + goto unlock_mutex; > >>>>>> + } > >>>>>> /* > >>>>>> * The flag must be set after the refcount is bumped > >>>>>> * otherwise it may race with THP split. > >>>>>> -- > >>>>>> 2.23.0 > >>>> > >>>> > >>> . > >>> > >> > > . > > > >