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 3D0E4C433F5 for ; Mon, 2 May 2022 05:59:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 643646B0072; Mon, 2 May 2022 01:59:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5F34B6B0073; Mon, 2 May 2022 01:59:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4BA6C6B0074; Mon, 2 May 2022 01:59:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.a.hostedemail.com [64.99.140.24]) by kanga.kvack.org (Postfix) with ESMTP id 3BDFF6B0072 for ; Mon, 2 May 2022 01:59:14 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id F10EA218E8 for ; Mon, 2 May 2022 05:59:13 +0000 (UTC) X-FDA: 79419750186.08.4BD2BB8 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf28.hostedemail.com (Postfix) with ESMTP id 8EFC3C0035 for ; Mon, 2 May 2022 05:59:01 +0000 (UTC) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 533A21FB; Sun, 1 May 2022 22:59:12 -0700 (PDT) Received: from [192.168.0.8] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 28B833F73D; Sun, 1 May 2022 22:58:56 -0700 (PDT) Message-ID: Date: Mon, 2 May 2022 11:29:34 +0530 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: [PATCH v2] mm/memory-failure.c: skip huge_zero_page in memory_failure() Content-Language: en-US To: =?UTF-8?B?SE9SSUdVQ0hJIE5BT1lBKOWggOWPoyDnm7TkuZ8p?= Cc: Yu Xu , "linux-mm@kvack.org" , Yang Shi , David Hildenbrand , "akpm@linux-foundation.org" , "linmiaohe@huawei.com" , "osalvador@suse.de" References: <497d3835612610e370c74e697ea3c721d1d55b9c.1649775850.git.xuyu@linux.alibaba.com> <8e1a882c-8568-57f2-216a-703f220e0e3f@linux.alibaba.com> <20220425141649.GB3767079@hori.linux.bs1.fc.nec.co.jp> <4a004118-ff5a-ca2e-e707-5886c41045b5@arm.com> <20220426065809.GA3847941@hori.linux.bs1.fc.nec.co.jp> From: Anshuman Khandual In-Reply-To: <20220426065809.GA3847941@hori.linux.bs1.fc.nec.co.jp> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 8EFC3C0035 X-Stat-Signature: krnqqww77oz3uqoidp8nyej77toga67t Authentication-Results: imf28.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf28.hostedemail.com: domain of anshuman.khandual@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=anshuman.khandual@arm.com X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1651471141-410765 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 4/26/22 12:28, HORIGUCHI NAOYA(堀口 直也) wrote: > On Tue, Apr 26, 2022 at 12:18:39PM +0530, Anshuman Khandual wrote: >> >> >> On 4/25/22 19:46, HORIGUCHI NAOYA(堀口 直也) wrote: >>> On Sat, Apr 23, 2022 at 11:16:20AM +0800, Yu Xu wrote: >>>> For this patch v2, >>>> >>>> Yang, David, Anshuman and Naoya all agree to fix the bug in >>>> split_huge_page_to_list(), i.e., to replace the BUG to >>>> WARN + returning -EBUSY for huge_zero_page. >>>> >>>> However, this patch v2 has just been merged into linux mainline. >>>> Sorry for that I didn't hurry up. >>>> >>>> So now, should we continue sending v3, or should we end this >>>> thread, and start a successive patch for optimization? >>> >>> No problem, you can start a new thread for additional patches. >>> Maybe it's better to have separate patches (starting with one >>> reverting v2 and then one doing v3). >> >> May be also pull in the following patch which adds MF_MSG_HUGE_ZERO >> in the same series ? >> >> https://lore.kernel.org/linux-mm/20220425080306.1771480-1-anshuman.khandual@arm.com/ > > I don't think so. I think that Yu's v3 would solely solve the reported > problem, so any check for huge_zero_page in memory_failire() should not > be needed. (But correct me if I miss something ...) Never mind, you are right.