[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZiCb_r8O24p8qHIz@localhost.localdomain>
Date: Thu, 18 Apr 2024 06:05:18 +0200
From: Oscar Salvador <osalvador@...e.de>
To: Miaohe Lin <linmiaohe@...wei.com>
Cc: akpm@...ux-foundation.org, muchun.song@...ux.dev, david@...hat.com,
vbabka@...e.cz, willy@...radead.org, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] mm/hugetlb: fix DEBUG_LOCKS_WARN_ON(1) when
dissolve_free_hugetlb_folio()
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.
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".
--
Oscar Salvador
SUSE Labs
Powered by blists - more mailing lists