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=-14.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,HK_RANDOM_FROM,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_2 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 7004CC433C1 for ; Wed, 31 Mar 2021 07:07:43 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 39289619CD for ; Wed, 31 Mar 2021 07:07:42 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 39289619CD Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kingsoft.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id C1C586B0081; Wed, 31 Mar 2021 03:07:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BF3156B0082; Wed, 31 Mar 2021 03:07:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A93296B0083; Wed, 31 Mar 2021 03:07:41 -0400 (EDT) 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 8E55A6B0081 for ; Wed, 31 Mar 2021 03:07:41 -0400 (EDT) Received: from smtpin35.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 3C4BC2826 for ; Wed, 31 Mar 2021 07:07:41 +0000 (UTC) X-FDA: 77979289122.35.99596ED Received: from mail.kingsoft.com (mail.kingsoft.com [114.255.44.145]) by imf03.hostedemail.com (Postfix) with ESMTP id 66B6BC0001EE for ; Wed, 31 Mar 2021 07:07:35 +0000 (UTC) X-AuditID: 0a580155-f55ff70000015057-51-60641fb423b1 Received: from mail.kingsoft.com (localhost [10.88.1.79]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail.kingsoft.com (SMG-2-NODE-85) with SMTP id 52.43.20567.4BF14606; Wed, 31 Mar 2021 15:07:32 +0800 (HKT) Received: from alex-virtual-machine (172.16.253.254) by KSBJMAIL4.kingsoft.cn (10.88.1.79) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Wed, 31 Mar 2021 15:07:32 +0800 Date: Wed, 31 Mar 2021 15:07:32 +0800 From: Aili Yao To: David Hildenbrand , "HORIGUCHI =?UTF-8?B?TkFPWUE=?=( =?UTF-8?B?5aCA5Y+jIOebtOS5nw==?=)" CC: Matthew Wilcox , "akpm@linux-foundation.org" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , "yangfeng1@kingsoft.com" , "sunhao2@kingsoft.com" , Oscar Salvador , Mike Kravetz , Subject: Re: [PATCH v5] mm/gup: check page hwposion status for coredump. Message-ID: <20210331150732.1b2906b4@alex-virtual-machine> In-Reply-To: <9f49c415-a75a-1ea3-b80c-5ba512331de6@redhat.com> References: <20a0d078-f49d-54d6-9f04-f6b41dd51e5f@redhat.com> <20210318044600.GJ3420@casper.infradead.org> <20210318133412.12078eb7@alex-virtual-machine> <20210319104437.6f30e80d@alex-virtual-machine> <20210320003516.GC3420@casper.infradead.org> <20210322193318.377c9ce9@alex-virtual-machine> <20210331015258.GB22060@hori.linux.bs1.fc.nec.co.jp> <20210331104303.145aea53@alex-virtual-machine> <20210331043231.GA26013@hori.linux.bs1.fc.nec.co.jp> <9f49c415-a75a-1ea3-b80c-5ba512331de6@redhat.com> Organization: kingsoft X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.30; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.16.253.254] X-ClientProxiedBy: KSBJMAIL1.kingsoft.cn (10.88.1.31) To KSBJMAIL4.kingsoft.cn (10.88.1.79) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLMWRmVeSWpSXmKPExsXCFcHor7tFPiXB4PtOC4s569ewWXxd/4vZ 4vKuOWwW99b8Z7X4uD/Y4mLjAUaLM9OKLH7/mMPmwOGxeYWWx6ZPk9g9Tsz4zeLx4upGFo+P T2+xeLzfd5XNY/Ppao/Pm+QCOKK4bFJSczLLUov07RK4Ms6sPs9S8EmrYvWDSWwNjLuVuhg5 OSQETCRmzpjG1sXIxSEkMJ1Jom/ecXYI5xWjxIaLa9hBqlgEVCVOTpjDCmKzAdm77s1iBSkS EehklFj7azOYwywwm1miY9JkNpAqYQEPiSMrToB18wpYSZxevpwFxOYUsJNYu3YCE8SKlywS 017OYwJJ8AuISfRe+c8EcZS9RNuWRYwQzYISJ2c+AWtmFtCUaN3+mx3C1pZYtvA1M4gtJKAo cXjJL3aIXiWJI90z2CDsWImmA7fYJjAKz0IyahaSUbOQjFrAyLyKkaU4N91oEyMkZkJ3MM5o +qh3iJGJg/EQowQHs5IIr/CBxAQh3pTEyqrUovz4otKc1OJDjNIcLErivN8fJCUICaQnlqRm p6YWpBbBZJk4OKUamHLr2CULP/r8apAqNxP1LXisGuOzWFFW5JdQzrGT86raDvl1vmC+Y/Gj rHeVvTD7S3khAdX0zrl22/cJ6fybW+SSlbltzlw/9dnh7SbZodIG+yweLl/5vJSDfe4JlTXs pxaqLRNtesi39YbV1cP3BExyQwunFwRFfcj9uuXJvN7nomUGxyfP2tjs/aFLzpmXe2l0xptZ 4gePPeJ68efTrq1ykT8Fz3QE2hw46n3+nucF548LN/6QzPwa+/Ti1so4zZDXliHZlXP/6VwV OTxJwS9rwe3k7j8XE36f19J0qjgsx/Yn4EnZlYtaEXtXvnrCcEhWmr+tMeHmlpRZZd42M5a7 5ZQLbNze8tf0GRNfjRJLcUaioRZzUXEiAMQ9Xt0IAwAA X-Stat-Signature: egg15483umbasawr7xgqkhhiurz7b8u9 X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 66B6BC0001EE Received-SPF: none (kingsoft.com>: No applicable sender policy available) receiver=imf03; identity=mailfrom; envelope-from=""; helo=mail.kingsoft.com; client-ip=114.255.44.145 X-HE-DKIM-Result: none/none X-HE-Tag: 1617174455-519340 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 Wed, 31 Mar 2021 08:44:53 +0200 David Hildenbrand wrote: > On 31.03.21 06:32, HORIGUCHI NAOYA(=E5=A0=80=E5=8F=A3 =E7=9B=B4=E4=B9=9F)= wrote: > > On Wed, Mar 31, 2021 at 10:43:36AM +0800, Aili Yao wrote: =20 > >> On Wed, 31 Mar 2021 01:52:59 +0000 HORIGUCHI NAOYA(=E5=A0=80=E5=8F=A3= =E3=80=80=E7=9B=B4=E4=B9=9F) wrote: =20 > >>> On Fri, Mar 26, 2021 at 03:22:49PM +0100, David Hildenbrand wrote: =20 > >>>> On 26.03.21 15:09, David Hildenbrand wrote: =20 > >>>>> On 22.03.21 12:33, Aili Yao wrote: =20 > >>>>>> When we do coredump for user process signal, this may be one SIGBU= S signal > >>>>>> with BUS_MCEERR_AR or BUS_MCEERR_AO code, which means this signal = is > >>>>>> resulted from ECC memory fail like SRAR or SRAO, we expect the mem= ory > >>>>>> recovery work is finished correctly, then the get_dump_page() will= not > >>>>>> return the error page as its process pte is set invalid by > >>>>>> memory_failure(). > >>>>>> > >>>>>> But memory_failure() may fail, and the process's related pte may n= ot be > >>>>>> correctly set invalid, for current code, we will return the poison= page, > >>>>>> get it dumped, and then lead to system panic as its in kernel code. > >>>>>> > >>>>>> So check the hwpoison status in get_dump_page(), and if TRUE, retu= rn NULL. > >>>>>> > >>>>>> There maybe other scenario that is also better to check hwposion s= tatus > >>>>>> and not to panic, so make a wrapper for this check, Thanks to Davi= d's > >>>>>> suggestion(). > >>>>>> > >>>>>> Link: https://lkml.kernel.org/r/20210319104437.6f30e80d@alex-virtu= al-machine > >>>>>> Signed-off-by: Aili Yao > >>>>>> Cc: David Hildenbrand > >>>>>> Cc: Matthew Wilcox > >>>>>> Cc: Naoya Horiguchi > >>>>>> Cc: Oscar Salvador > >>>>>> Cc: Mike Kravetz > >>>>>> Cc: Aili Yao > >>>>>> Cc: stable@vger.kernel.org > >>>>>> Signed-off-by: Andrew Morton > >>>>>> --- > >>>>>> mm/gup.c | 4 ++++ > >>>>>> mm/internal.h | 20 ++++++++++++++++++++ > >>>>>> 2 files changed, 24 insertions(+) > >>>>>> > >>>>>> diff --git a/mm/gup.c b/mm/gup.c > >>>>>> index e4c224c..6f7e1aa 100644 > >>>>>> --- a/mm/gup.c > >>>>>> +++ b/mm/gup.c > >>>>>> @@ -1536,6 +1536,10 @@ struct page *get_dump_page(unsigned long ad= dr) > >>>>>> FOLL_FORCE | FOLL_DUMP | FOLL_GET); > >>>>>> if (locked) > >>>>>> mmap_read_unlock(mm); =20 > >>>>> > >>>>> Thinking again, wouldn't we get -EFAULT from __get_user_pages_locke= d() > >>>>> when stumbling over a hwpoisoned page? > >>>>> > >>>>> See __get_user_pages_locked()->__get_user_pages()->faultin_page(): > >>>>> > >>>>> handle_mm_fault()->vm_fault_to_errno(), which translates > >>>>> VM_FAULT_HWPOISON to -EFAULT, unless FOLL_HWPOISON is set (-> -EHWP= OISON) > >>>>> > >>>>> ? =20 > >>> > >>> We could get -EFAULT, but sometimes not (depends on how memory_failur= e() fails). > >>> > >>> If we failed to unmap, the page table is not converted to hwpoison en= try, > >>> so __get_user_pages_locked() get the hwpoisoned page. > >>> > >>> If we successfully unmapped but failed in truncate_error_page() for e= xample, > >>> the processes mapping the page would get -EFAULT as expected. But ev= en in > >>> this case, other processes could reach the error page via page cache = and > >>> __get_user_pages_locked() for them could return the hwpoisoned page. > >>> =20 > >>>> > >>>> Or doesn't that happen as you describe "But memory_failure() may fai= l, and > >>>> the process's related pte may not be correctly set invalid" -- but w= hy does > >>>> that happen? =20 > >>> > >>> Simply because memory_failure() doesn't handle some page types like k= sm page > >>> and zero page. Or maybe shmem thp also belongs to this class. =20 >=20 > Thanks for that info! >=20 > >>> =20 > >>>> > >>>> On a similar thought, should get_user_pages() never return a page th= at has > >>>> HWPoison set? E.g., check also for existing PTEs if the page is hwpo= isoned? =20 > >>> > >>> Make sense to me. Maybe inserting hwpoison check into follow_page_pte= () and > >>> follow_huge_pmd() would work well. =20 > >> > >> I think we should take more care to broadcast the hwpoison check to ot= her cases, > >> SIGBUS coredump is such a case that it is supposed to not touch the po= ison page, > >> and if we return NULL for this, the coredump process will get a succes= sful finish. > >> > >> Other cases may also meet the requirements like coredump, but we need = to identify it, > >> that's the poison check wrapper's purpose. If not, we may break the in= tegrity of the > >> related action, which may be no better than panic. =20 > >=20 > > If you worry about regression and would like to make this new behavior = conditional, > > we could use FOLL_HWPOISON to specify that the caller is hwpoison-aware= so that > > any !FOLL_HWPOISON caller ignores the hwpoison check and works as it do= es now. > > This approach looks to me helpful because it would encourage developers= touching > > gup code to pay attention to FOLL_HWPOISON code. =20 >=20 > FOLL_HWPOISON might be the right start, indeed. >=20 Got this, Thanks! I will dig more! --=20 Thanks! Aili Yao