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 D12D3C4345F for ; Thu, 18 Apr 2024 08:00:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3ACB66B0087; Thu, 18 Apr 2024 04:00:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3338F6B0088; Thu, 18 Apr 2024 04:00:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1D4366B0089; Thu, 18 Apr 2024 04:00:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id EFD5F6B0087 for ; Thu, 18 Apr 2024 04:00:53 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 5AFCC14111F for ; Thu, 18 Apr 2024 08:00:53 +0000 (UTC) X-FDA: 82021906386.01.AF285E7 Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [45.249.212.190]) by imf16.hostedemail.com (Postfix) with ESMTP id 1DD0518000D for ; Thu, 18 Apr 2024 08:00:49 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf16.hostedemail.com: domain of linmiaohe@huawei.com designates 45.249.212.190 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=1713427251; 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=evdBj4qZlq+gkIA46fxWNcfal9SI0sHZJ1X+nBD+f9w=; b=3rGb4F6U6PL0+wfjZQAQ93qElm9JOlHE0oXwm3f6l9WdXQ8Yc81/KCHJZkd6xf7phzs+sd AMi7/lEkGicwTf28DJoeVxYS+turhXNxQ7+oP4eP3k4Wxy4NF/N2i3Rkal35rVeQXAM6H/ ka1Q2n/AxRnLZfUY1R3FCclTLt6kBB0= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf16.hostedemail.com: domain of linmiaohe@huawei.com designates 45.249.212.190 as permitted sender) smtp.mailfrom=linmiaohe@huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1713427251; a=rsa-sha256; cv=none; b=icUUhynJan0lplNzT0QR51+8u5UnMtKhE8WEhPi6Rx3kRa68egL98X+W+iLQb3GENGrjwm 26pg+Gs2s4vPRbidAXNPpk+VJRgTQ5Sk3r9gn1ETihpNAzuAAsjDELwOYrxwLngiu0CRvs 6ccTJT231IH/N4JRW68g9jZ+tUwu8aU= Received: from mail.maildlp.com (unknown [172.19.88.214]) by szxga04-in.huawei.com (SkyGuard) with ESMTP id 4VKqs72Pnqz1xtxL; Thu, 18 Apr 2024 15:58:19 +0800 (CST) Received: from canpemm500002.china.huawei.com (unknown [7.192.104.244]) by mail.maildlp.com (Postfix) with ESMTPS id 9C6011A016C; Thu, 18 Apr 2024 16:00:43 +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; Thu, 18 Apr 2024 16:00:43 +0800 Subject: Re: [PATCH 1/2] mm/hugetlb: fix DEBUG_LOCKS_WARN_ON(1) when dissolve_free_hugetlb_folio() To: Oscar Salvador CC: , , , , , , References: <20240418022000.3524229-1-linmiaohe@huawei.com> <20240418022000.3524229-2-linmiaohe@huawei.com> From: Miaohe Lin Message-ID: Date: Thu, 18 Apr 2024 16:00:42 +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.173.135.154] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To canpemm500002.china.huawei.com (7.192.104.244) X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 1DD0518000D X-Rspam-User: X-Stat-Signature: 4zxrx1izbs41ymzqnfda9czr4bi3art7 X-HE-Tag: 1713427249-417481 X-HE-Meta: U2FsdGVkX1/fqyEKwB2BLYhMYmfEzIFYzDSwjg5mNwR12TrtduqXlKYp7svIPtAnYxCFaBcC1yiq9Ynx2oNA/td/+MxhYT/SEJdWSBgteRVDZvCUGbkEXbkfzXQtQ9diW4pkcD3v1lPc+XR5muWvaY2nf60q80MwwBlEZ6ezyGzLCt3s57va9XeeVThquyW4zhnyDNGFW0LUqsqY5PXqH8PUaFjODAl2rxzAXlRyc59+6vOf2mMpvlZMsh54T4gJxYS1tQn7EgU7rQxi3LIeAvqkxm1jMRH2BWguq+NLhGF6jSo2SVCg/iGDmytvdq1floNkDZjFisdyYfMJxTbmqmjGLu3/qb7k5Yu3feTyoVXr6ry0JshKtF/+IvRzEMNMmNaNNM4ONloJ70THiQvTf/GDID1a7PyAXle9DJqDRCZ50y9Q42schc0f2coonA+LZOwyQ6Ri011vW9qYe78I8qcdAYPmSa4ebaXntSFgqV2luGhOuBQ1nhtU2doYHACvNT52hoS/kiYlPWK7WX5PoiaMkkXGuipynQ7DtyeIAHoaXCJJNtDN0OEyl/IlBh28aa2UL+HiXF+IjOUQjRzt7oIEmz8ye9sFbCpL7ltNoOiuSk8WipIwEDrMFmg6GgkncBY2tfRekgYABpJ3SofsnV+U9y0jou9lxlwh7i6bVYQrtjSd1eOOnw767hJZlOaFjJvQ6E+82pEBKEpUwsRcLuJqtS8dClnUrsh6KtGiplIQWLlaEsElJgo7jw9ofq9itm/pQXBvW3DdOKdwgqs4wPRgwCaX/1eJV5FfdZej6JgC2HDBdGgt85Ph1HjhKRYl3yC5HGCAFTCPcKkNAf5MCV+1RIA4wp2X7oEeCYjDD9q96vvTMRJH4m3RO0HxUtw3H9sR8bpgw1JVwEGgOpmdZ0exq3HJ3fg+5oZq+2yhfHJVE2RvnLIWt26cTe1QqNVcuJqomKVGjlsQ4Ats0rM o+I1Aal7 mpMW8lnksbrB0a//3s3BAjx3jN6Jskn9R2HDRsTBFC1PlBXT30GbpDGVbgc2WDVNhLwQq1iMJShJo2bUr105G+u0ntE/ida4XF09TK8rOFOhNKcETJ6CDXiEx9ElIntiJXmyC1KzmYeJNvMvuWR0N4ryqA2G3vjiNiZoQgnAM9HwlMDK6WEkTTU0jQg== 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/4/18 12:05, Oscar Salvador wrote: > On Thu, Apr 18, 2024 at 10:19:59AM +0800, Miaohe Lin wrote: >> diff --git a/mm/hugetlb.c b/mm/hugetlb.c >> index 26ab9dfc7d63..1da9a14a5513 100644 >> --- a/mm/hugetlb.c >> +++ b/mm/hugetlb.c >> @@ -1788,7 +1788,8 @@ static void __update_and_free_hugetlb_folio(struct hstate *h, >> destroy_compound_gigantic_folio(folio, huge_page_order(h)); >> free_gigantic_folio(folio, huge_page_order(h)); >> } else { >> - INIT_LIST_HEAD(&folio->_deferred_list); >> + if (!folio_test_hugetlb(folio)) >> + INIT_LIST_HEAD(&folio->_deferred_list); > > Ok, it took me a bit to figure this out. > > So we basically init __deferred_list when we know that > folio_put will not end up calling free_huge_folio > because a previous call to remove_hugetlb_folio has already cleared the > bit. > > Maybe Matthew thought that any folio ending here would not end up in > free_huge_folio (which is the one fiddling subpool). > > I mean, fix looks good because if hugetlb flag is cleared, > destroy_large_folio will go straight to free_the_page, but the > whole thing is a bit subtle. AFAICS, this is the most straightforward way to fix the issue. Do you have any suggestions on how to fix this in a more graceful way? > > And if we decide to go with this, I think we are going to need a comment > in there explaining what is going on like "only init _deferred_list if > free_huge_folio cannot be call". Yes, this comment will help. Thanks. . > >