[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aC63fmFKK84K7YiZ@localhost.localdomain>
Date: Thu, 22 May 2025 07:34:54 +0200
From: Oscar Salvador <osalvador@...e.de>
To: Muchun Song <muchun.song@...ux.dev>
Cc: yangge1116@....com, akpm@...ux-foundation.org, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, stable@...r.kernel.org,
21cnbao@...il.com, david@...hat.com, baolin.wang@...ux.alibaba.com,
liuzixing@...on.cn
Subject: Re: [PATCH] mm/hugetlb: fix kernel NULL pointer dereference when
replacing free hugetlb folios
On Thu, May 22, 2025 at 11:47:05AM +0800, Muchun Song wrote:
> Thanks for fixing this problem. BTW, in order to catch future similar problem,
> it is better to add WARN_ON into folio_hstate() to assert if hugetlb_lock
> is not held when folio's reference count is zero. For this fix, LGTM.
Why cannot we put all the burden in alloc_and_dissolve_hugetlb_folio(),
which will again check things under the lock?
I mean, I would be ok to save cycles and check upfront in
replace_free_hugepage_folios(), but the latter has only one user which
is alloc_contig_range(), which is not really an expected-to-be optimized
function.
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index bd8971388236..b4d937732256 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -2924,13 +2924,6 @@ int replace_free_hugepage_folios(unsigned long start_pfn, unsigned long end_pfn)
while (start_pfn < end_pfn) {
folio = pfn_folio(start_pfn);
- if (folio_test_hugetlb(folio)) {
- h = folio_hstate(folio);
- } else {
- start_pfn++;
- continue;
- }
-
if (!folio_ref_count(folio)) {
ret = alloc_and_dissolve_hugetlb_folio(h, folio,
&isolate_list);
--
Oscar Salvador
SUSE Labs
Powered by blists - more mailing lists