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 39401C433F5 for ; Tue, 12 Apr 2022 10:58:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 59DD06B007B; Tue, 12 Apr 2022 06:58:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 54D586B007E; Tue, 12 Apr 2022 06:58:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 43C7C6B0080; Tue, 12 Apr 2022 06:58:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0175.hostedemail.com [216.40.44.175]) by kanga.kvack.org (Postfix) with ESMTP id 3448A6B007B for ; Tue, 12 Apr 2022 06:58:57 -0400 (EDT) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id D89808249980 for ; Tue, 12 Apr 2022 10:58:56 +0000 (UTC) X-FDA: 79347929472.24.86F42E5 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by imf29.hostedemail.com (Postfix) with ESMTP id B5607120004 for ; Tue, 12 Apr 2022 10:58:55 +0000 (UTC) Received: from canpemm500002.china.huawei.com (unknown [172.30.72.53]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4Kd2j86Bx4zgYh3; Tue, 12 Apr 2022 18:56:44 +0800 (CST) Received: from [10.174.177.76] (10.174.177.76) by canpemm500002.china.huawei.com (7.192.104.244) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Tue, 12 Apr 2022 18:58:33 +0800 Subject: Re: [PATCH] mm/memory-failure.c: bail out early if huge zero page To: Oscar Salvador CC: , , Xu Yu References: <49273e6688d7571756603dac996692a15f245d58.1649603963.git.xuyu@linux.alibaba.com> From: Miaohe Lin Message-ID: Date: Tue, 12 Apr 2022 18:58:33 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.177.76] X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) To canpemm500002.china.huawei.com (7.192.104.244) X-CFilter-Loop: Reflected Authentication-Results: imf29.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf29.hostedemail.com: domain of linmiaohe@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=linmiaohe@huawei.com X-Rspam-User: X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: B5607120004 X-Stat-Signature: 8jpzrg9896wya6sxu7axcr8888jz39t7 X-HE-Tag: 1649761135-770938 X-Bogosity: Ham, tests=bogofilter, spamicity=0.002195, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 2022/4/12 17:30, Oscar Salvador wrote: > On Tue, Apr 12, 2022 at 05:25:52PM +0800, Miaohe Lin wrote: >> On 2022/4/12 16:31, Oscar Salvador wrote: >>> On Sun, Apr 10, 2022 at 11:22:34PM +0800, Xu Yu wrote: >>>> Kernel panic when injecting memory_failure for the global huge_zero_page, >>>> when CONFIG_DEBUG_VM is enabled, as follows. >>> ... >>>> In fact, huge_zero_page is unhandlable currently in either soft offline >>>> or memory failure injection. With CONFIG_DEBUG_VM disabled, >>>> huge_zero_page is bailed out when checking HWPoisonHandlable() in >>>> get_any_page(), or checking page mapping in split_huge_page_to_list(). >>>> >>>> This makes huge_zero_page bail out early in madvise_inject_error(), and >>>> panic above won't happen again. >>> >>> I would not special case this in madvise_inject_error() but rather >>> handle it in memory-failure code. >>> We do already have HWPoisonHandlable(), which tells us whether the page >>> is of a type we can really do something about, so why not add another >>> check in HWPoisonHandlable() for huge_zero_page(), and have that checked >>> in memory_failure(). >> >> IIUC, this does not work. Because HWPoisonHandlable is only called in !MF_COUNT_INCREASED case. >> But MF_COUNT_INCREASED is always set when called from madvise_inject_error, so HWPoisonHandlable >> is not even called in this scene. Or am I miss something? > > But nothing stops you from calling it in memory_failure(), right? > > if (MF_COUNT_INCREASED not set) { > .... > ... > } else if(!HWPoisonHandable(p)) { > action_result(pfn, MF_MSG_UNKNOWN, MF_IGNORED); > res = -EBUSY; > goto unlock_mutex; > } Yes, I somewhat misread the proposed code. Thanks for clarifying. :) > >> BTW: IIRC, LRU isn't set on huge_zero_page. So the origin HWPoisonHandlable can already filter out this page. > > I would rather have it as a explicit check than buried in that kind of > assumption. > > But after all, Naoya's suggestion might just be better and more focused. > >