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 8B521C433F5 for ; Tue, 17 May 2022 12:03:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 03ADF6B0072; Tue, 17 May 2022 08:03:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F2ABE6B0073; Tue, 17 May 2022 08:03:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E19826B0074; Tue, 17 May 2022 08:03:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id CEA476B0072 for ; Tue, 17 May 2022 08:03:11 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 87DE120A57 for ; Tue, 17 May 2022 12:03:11 +0000 (UTC) X-FDA: 79475099382.12.4679C85 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by imf01.hostedemail.com (Postfix) with ESMTP id 75FD3400C8 for ; Tue, 17 May 2022 12:02:54 +0000 (UTC) Received: from dggpemm500024.china.huawei.com (unknown [172.30.72.53]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4L2ZSB18ZczGpcx; Tue, 17 May 2022 20:00:10 +0800 (CST) Received: from dggpemm100009.china.huawei.com (7.185.36.113) by dggpemm500024.china.huawei.com (7.185.36.203) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Tue, 17 May 2022 20:03:03 +0800 Received: from [10.174.179.24] (10.174.179.24) by dggpemm100009.china.huawei.com (7.185.36.113) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Tue, 17 May 2022 20:03:03 +0800 Subject: Re: Question about hwpoison handling of 1GB hugepage To: =?UTF-8?B?SE9SSUdVQ0hJIE5BT1lBKOWggOWPo+OAgOebtOS5nyk=?= References: <0af88a11-4dfe-9a4e-7b94-08f12caafcf3@huawei.com> <20220403234250.GA2217943@hori.linux.bs1.fc.nec.co.jp> CC: Andrew Morton , "linux-mm@kvack.org" , Linux Kernel Mailing List From: Liu Shixin Message-ID: Date: Tue, 17 May 2022 20:03:03 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <20220403234250.GA2217943@hori.linux.bs1.fc.nec.co.jp> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.179.24] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To dggpemm100009.china.huawei.com (7.185.36.113) X-CFilter-Loop: Reflected X-Rspamd-Queue-Id: 75FD3400C8 X-Stat-Signature: ok8t87amocry5yg65jsjhhtxrzt8fayg X-Rspam-User: Authentication-Results: imf01.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf01.hostedemail.com: domain of liushixin2@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=liushixin2@huawei.com X-Rspamd-Server: rspam09 X-HE-Tag: 1652788974-41299 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: Hello Naoya, Is there any progress on memory error handling on 1GB hugepage : ) Thanks, Liu Shixin On 2022/4/4 7:42, HORIGUCHI NAOYA(堀口　直也) wrote: > On Thu, Mar 31, 2022 at 06:56:25PM +0800, Liu Shixin wrote: >> Hi, >> >> Recently, I found a problem with hwpoison 1GB hugepage. >> I created a process and mapped 1GB hugepage. This process will then fork a >> child process and write/read this 1GB hugepage. Then I inject hwpoison into >> this 1GB hugepage. The child process triggers the memory failure and is >> being killed as expected. After this, the parent process will try to fork a >> new child process and do the same thing. It is killed again and finally it >> goes into such an infinite loop. I found this was caused by >> commit 31286a8484a8 ("mm: hwpoison: disable memory error handling on 1GB hugepage") > Hello Shixin, > > It's little unclear to me about what behavior you are expecting and > what the infinite loop repeats, could you explain little more about them? > (I briefly tried to reproduce it, but didn't make it...) > >> It looks like there is a bug for hwpoison 1GB hugepage so I try to reproduce >> the bug described. After trying to revert the patch in an earlier version of >> the kernel, I reproduce the bug described. Then I try to revert the patch in >> latest version, and find the bug is no longer reproduced. >> >> I compare the code paths of 1 GB hugepage and 2 MB hugepage for second madvise(MADV_HWPOISON), >> and find that the problem is caused because in gup_pud_range(), pud_none() and >> pud_huge() both return false and then trigger the bug. But in gup_pmd_range(), >> the pmd_none() is modified to pmd_present() which will make code return directly. >> The I find that it is commit 15494520b776 ("mm: fix gup_pud_range") which >> cause latest version not reproduced. I backport commit 15494520b776 in >> earlier version and find the bug is no longer reproduced either. > Thank you for the analysis. > So this patch might make 31286a8484a8 unnecessary, that's a good news. > >> So I'd like to consult that is it the time to revert commit 31286a8484a8? >> Or if we modify pud_huge to be similar with pmd_huge, is it sufficient? >> >> I also noticed there is a TODO comment in memory_failure_hugetlb(): >> - conversion of a pud that maps an error hugetlb into hwpoison >> entry properly works, and >> - other mm code walking over page table is aware of pud-aligned >> hwpoison entries. > These are simply minimum requirements, but might not be sufficient. > We need testing (with removing 31286a8484a8) to make sure that > there's no issues on some corner cases. > (I start to extend existing hugetlb-related testcases to 1GB ones.) > > Thanks, > Naoya Horiguchi > >> I'm not sure whether the above fix are sufficient, so is there anything else need >> to analysis that I haven't considered?