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 4E20AC54E58 for ; Fri, 15 Mar 2024 08:32:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D54C880105; Fri, 15 Mar 2024 04:32:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D0347800B4; Fri, 15 Mar 2024 04:32:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B7CE180105; Fri, 15 Mar 2024 04:32:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id A7754800B4 for ; Fri, 15 Mar 2024 04:32:18 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 2DD7380EDC for ; Fri, 15 Mar 2024 08:32:18 +0000 (UTC) X-FDA: 81898606356.20.EBE401F Received: from szxga05-in.huawei.com (szxga05-in.huawei.com [45.249.212.191]) by imf09.hostedemail.com (Postfix) with ESMTP id 95E3F140004 for ; Fri, 15 Mar 2024 08:32:14 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf09.hostedemail.com: domain of linmiaohe@huawei.com designates 45.249.212.191 as permitted sender) smtp.mailfrom=linmiaohe@huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1710491536; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=5E2PxWfjueLBBTsD2++aJ8BiomqYU99+gj1wAzspFOE=; b=b30b0JVlMD2Z0tQViJRUO7fS5+nPn4QPXO5FoEAjuTSYUsIFalyPWILsOsTIRG2QpUIgOX xeKId+WQzgGdfKFZCcOScBUQZMWM6TlR1A+x9NC55fPK88fWlJADFmYGttya3y+UGGzm8n 2o1Ne9nAet3pRL25v+KJZ+XvBlsRe2E= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf09.hostedemail.com: domain of linmiaohe@huawei.com designates 45.249.212.191 as permitted sender) smtp.mailfrom=linmiaohe@huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1710491536; a=rsa-sha256; cv=none; b=MOsKZ0+A7LyprpayVl5kssyYZl411E2KkgjmBxdZl14FcGD57wIgy0tV+ZzZLfK5qKVgqy dwVICEJTvsLKo4Rpv2tj0qZy1M5IVPkBZj3Q3QaK6NisncXD4PMAYAgCJDifkBxw3Hkw1i CKVEN/vaxsYd1qNlBbREKJdwnXJ3zGk= Received: from mail.maildlp.com (unknown [172.19.88.163]) by szxga05-in.huawei.com (SkyGuard) with ESMTP id 4Twy911nb2z1h2QW; Fri, 15 Mar 2024 16:29:41 +0800 (CST) Received: from canpemm500002.china.huawei.com (unknown [7.192.104.244]) by mail.maildlp.com (Postfix) with ESMTPS id 057E318005F; Fri, 15 Mar 2024 16:32:10 +0800 (CST) Received: from [10.173.135.154] (10.173.135.154) by canpemm500002.china.huawei.com (7.192.104.244) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.35; Fri, 15 Mar 2024 16:32:09 +0800 Subject: Re: [PATCH 6/8] mm/memory-failure: Convert memory_failure() to use a folio To: Jane Chu CC: , Naoya Horiguchi , Andrew Morton , , Matthew Wilcox References: <20240229212036.2160900-1-willy@infradead.org> <20240229212036.2160900-7-willy@infradead.org> <5eab08d7-ae38-4f99-401f-f361466e34e0@huawei.com> <196d00e3-4335-4f8f-ac51-5ccfa5ef5f75@oracle.com> From: Miaohe Lin Message-ID: <55a1600d-340b-3262-99c7-8a30d6a92a84@huawei.com> Date: Fri, 15 Mar 2024 16:32:09 +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: <196d00e3-4335-4f8f-ac51-5ccfa5ef5f75@oracle.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [10.173.135.154] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To canpemm500002.china.huawei.com (7.192.104.244) X-Rspamd-Queue-Id: 95E3F140004 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: t511w3ymcykhox8cgjk8dyrczusnnjbf X-HE-Tag: 1710491534-13278 X-HE-Meta: U2FsdGVkX1+k1u/WpU3VCCN0meNqO575UnUZzHKLF6eVGcnYjymcMWWZToaMisU4U7iRKEEtlp6dsAk2o+tkljTzFoWpafwbuzo4Z0P3isxaAXcqwar8kKPxlpknjFTGMJiP8mUInhmQdg0ORQQce1i9J/CiHd89habP6j6TZ3Lpw4HCKP2Iks5WkvtNEtVBeJdjBJfAPMsR7YasYQjlR12h3JKe/2xtGtN8xpG1KJLuiD1jDADiCEeiOycF9sRpS3LgSz6DU/usx+ykZHQSkl4k00j0m+TcNCYKw1QuKaogEv+1JdOrhpGBQQ4n6qvjQxiOs9lXMSE1Peq4ccXvsa4N33wxqN2W677WV0bpU+raJEeSG2jKUFtuq7xq1lqOAIW4/0dIO9JoEECb7vFDsQqF9jUDzuYnrWMoRFSTxksVDQ4/YBSaA+IWVgpC2TFV3YzN3HCGNFrrSwhPfFxC/Gxcda/viSE6qpzEa/Ln8QYFwo7ORx3m+N3igbKserM15gbG5YuefOFyYrrSwFe58IL5xBBC2VzwrSW2n1FE5kNQmIXrROfDstzkv2WKCUlWZUNQEk+VlLExtVtyyG77YEoSmOsFTaNOWAg08kS48q5EVK/N9WbvKoykFuNotxS+5mufzp3syMQCMZgS0e7GJnDK2P99w6Fr6sOzugHUpe88qTuf+Pmfat4kKWb7/48O+1bsM4m7tWI3p2WGPqrf9t97R8kyt4c/4kRpfk1k7rfNzRtV2nkB3wBn5SjeLwbjN3eZ9612HD7307rZ1TuvndcQBn7uRKmcKE8099Efa016uFwTi2savMKfildheoU+AKnmyw+RaK+aDYnRbnZiQBBLWgj90UZb 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: List-Subscribe: List-Unsubscribe: On 2024/3/13 9:23, Jane Chu wrote: > On 3/12/2024 7:14 AM, Matthew Wilcox wrote: > >> On Tue, Mar 12, 2024 at 03:07:39PM +0800, Miaohe Lin wrote: >>> On 2024/3/11 20:31, Matthew Wilcox wrote: >>>> Assuming we have a refcount on this page so it can't be simultaneously >>>> split/freed/whatever, these three sequences are equivalent: >>> If page is stable after page refcnt is held, I agree below three sequences are equivalent. >>> >>>> 1    if (PageCompound(p)) >>>> >>>> 2    struct page *head = compound_head(p); >>>> 2    if (PageHead(head)) >>>> >>>> 3    struct folio *folio = page_folio(p); >>>> 3    if (folio_test_large(folio)) >>>> >>>> . >>>> >>> But please see below commit: >>> >>> """ >>> commit f37d4298aa7f8b74395aa13c728677e2ed86fdaf >>> Author: Andi Kleen >>> Date:   Wed Aug 6 16:06:49 2014 -0700 >>> >>>      hwpoison: fix race with changing page during offlining >>> >>>      When a hwpoison page is locked it could change state due to parallel >>>      modifications.  The original compound page can be torn down and then >>>      this 4k page becomes part of a differently-size compound page is is a >>>      standalone regular page. >>> >>>      Check after the lock if the page is still the same compound page. >> I can't speak to what the rules were ten years ago, but this is not >> true now.  Compound pages cannot be split if you hold a refcount. >> Since we don't track a per-page refcount, we wouldn't know which of >> the split pages to give the excess refcount to. > > I noticed this recently > >  * GUP pin and PG_locked transferred to @page. Rest subpages can be freed if >  * they are not mapped. >  * >  * Returns 0 if the hugepage is split successfully. >  * Returns -EBUSY if the page is pinned or if anon_vma disappeared from under >  * us. >  */ > int split_huge_page_to_list(struct page *page, struct list_head *list) > { > > I have a test case with poisoned shmem THP page that was mlocked and > > GUP pinned (FOLL_LONGTERM|FOLL_WRITE), but the split succeeded. Can you elaborate your test case a little bit more detail? There is a check in split_huge_page_to_list(): /* Racy check whether the huge page can be split */ bool can_split_folio(struct folio *folio, int *pextra_pins) { int extra_pins; /* Additional pins from page cache */ if (folio_test_anon(folio)) extra_pins = folio_test_swapcache(folio) ? folio_nr_pages(folio) : 0; else extra_pins = folio_nr_pages(folio); if (pextra_pins) *pextra_pins = extra_pins; return folio_mapcount(folio) == folio_ref_count(folio) - extra_pins - 1; } So a large folio can only be split if only one extra page refcnt is held. It means large folio won't be split from under us if we hold an page refcnt. Or am I miss something? Thanks. > > thanks, > > -jane > > .