Received-SPF: pass (google.com: domain of linux-kernel+bounces-150936-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Subject: Re: [PATCH 1/2] mm/hugetlb: fix DEBUG_LOCKS_WARN_ON(1) when
 dissolve_free_hugetlb_folio()
To: Oscar Salvador <osalvador@suse.de>
CC: <akpm@linux-foundation.org>, <muchun.song@linux.dev>, <david@redhat.com>,
	<vbabka@suse.cz>, <willy@infradead.org>, <linux-mm@kvack.org>,
	<linux-kernel@vger.kernel.org>
References: <20240418022000.3524229-1-linmiaohe@huawei.com>
 <20240418022000.3524229-2-linmiaohe@huawei.com>
 <ZiCb_r8O24p8qHIz@localhost.localdomain>
 <a852eb0c-f64e-f1d7-d685-a4e81a6416c6@huawei.com>
 <ZiEU83kaHP7AG25z@localhost.localdomain>
From: Miaohe Lin <linmiaohe@huawei.com>
Message-ID: <32c97464-fcc2-18a2-5b72-8602cffa895a@huawei.com>
Date: Fri, 19 Apr 2024 10:00:29 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.6.0
Precedence: bulk
MIME-Version: 1.0
In-Reply-To: <ZiEU83kaHP7AG25z@localhost.localdomain>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit

On 2024/4/18 20:41, Oscar Salvador wrote:
> On Thu, Apr 18, 2024 at 04:00:42PM +0800, Miaohe Lin wrote:
>> 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?
> 
> Not from the top of my head.
> Anyway, I have been thinking for a while that this code needs some love,
> so I will check how this can be untangled.

That would be really nice. Thanks Oscar.
.

> 
>