Messages in this thread | | | Date | Thu, 18 Apr 2024 06:05:18 +0200 | From | Oscar Salvador <> | 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
| |