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 1F50DC433F5 for ; Thu, 31 Mar 2022 10:56:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8EF2F6B0072; Thu, 31 Mar 2022 06:56:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 89DA06B0073; Thu, 31 Mar 2022 06:56:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 78D5B6B0074; Thu, 31 Mar 2022 06:56:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0024.hostedemail.com [216.40.44.24]) by kanga.kvack.org (Postfix) with ESMTP id 6AB8C6B0072 for ; Thu, 31 Mar 2022 06:56:31 -0400 (EDT) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 187ACA4A4E for ; Thu, 31 Mar 2022 10:56:31 +0000 (UTC) X-FDA: 79304377782.28.FA05F79 Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by imf21.hostedemail.com (Postfix) with ESMTP id 4C02A1C000A for ; Thu, 31 Mar 2022 10:56:30 +0000 (UTC) Received: from dggpemm500022.china.huawei.com (unknown [172.30.72.57]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4KTgFz2MNRzdZLs; Thu, 31 Mar 2022 18:56:07 +0800 (CST) Received: from dggpemm100009.china.huawei.com (7.185.36.113) by dggpemm500022.china.huawei.com (7.185.36.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Thu, 31 Mar 2022 18:56:26 +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.2308.21; Thu, 31 Mar 2022 18:56:26 +0800 To: Naoya Horiguchi , Andrew Morton From: Liu Shixin CC: , Linux Kernel Mailing List Subject: Question about hwpoison handling of 1GB hugepage Message-ID: <0af88a11-4dfe-9a4e-7b94-08f12caafcf3@huawei.com> Date: Thu, 31 Mar 2022 18:56:25 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit 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 Authentication-Results: imf21.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf21.hostedemail.com: domain of liushixin2@huawei.com designates 45.249.212.187 as permitted sender) smtp.mailfrom=liushixin2@huawei.com X-Stat-Signature: zpyd3fj6jk7pfooq6crocgrpo9fxgrhx X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 4C02A1C000A X-HE-Tag: 1648724190-75428 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: 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") 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. 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. I'm not sure whether the above fix are sufficient, so is there anything else need to analysis that I haven't considered? Thanks,