linux-kernel - Re: [PATCH] huge_memory: return -EINVAL in folio split functions when THP is disabled

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <519df8fd-b02d-4b4b-bf47-79070e3d2c9e@pankajraghav.com>
Date: Tue, 2 Sep 2025 15:02:23 +0200
From: Pankaj Raghav <kernel@...kajraghav.com>
To: Kiryl Shutsemau <kirill@...temov.name>
Cc: David Hildenbrand <david@...hat.com>, Ryan Roberts
 <ryan.roberts@....com>, Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
 Baolin Wang <baolin.wang@...ux.alibaba.com>, Dev Jain <dev.jain@....com>,
 Barry Song <baohua@...nel.org>, Andrew Morton <akpm@...ux-foundation.org>,
 Nico Pache <npache@...hat.com>, Zi Yan <ziy@...dia.com>,
 "Liam R . Howlett" <Liam.Howlett@...cle.com>, linux-kernel@...r.kernel.org,
 linux-mm@...ck.org, willy@...radead.org, mcgrof@...nel.org,
 gost.dev@...sung.com, Pankaj Raghav <p.raghav@...sung.com>
Subject: Re: [PATCH] huge_memory: return -EINVAL in folio split functions when
 THP is disabled

>> I was hitting a weird stale content read error and finally ended up with this fix.
>>
>> I thought this is a self-contained patch that can already be upstream. My argument is not that this
>> should not be reachable, but returning -EINVAL will do the right thing instead of returning 0, which
>> means success.
> 
> Okay, makes sense.
> 
> In THP=y case, __folio_split() also returns -EINVAL for !large folios,
> but it is not very explicit:
> 
> 	if (new_order >= folio_order(folio))
> 		return -EINVAL;
> 
> In THP=y, we also issue warning:
> 
> 	VM_WARN_ON_ONCE_FOLIO(!folio_test_locked(folio), folio);
> 
You mean:

VM_WARN_ON_ONCE_FOLIO(!folio_test_large(folio), folio);

> Makes sense to do the same here for THP=n. It might help to catch cases
> we do not see with THP=y, like getting non-THP large folios here.
> 

Yeah, I think that is a good idea. Something like this:

diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
index 48c4f91c5b13..4ddf9e87db91 100644
--- a/include/linux/huge_mm.h
+++ b/include/linux/huge_mm.h
@@ -588,21 +588,29 @@ static inline int
 split_huge_page_to_list_to_order(struct page *page, struct list_head *list,
                unsigned int new_order)
 {
+       struct folio *folio = page_folio(page);
+
+       VM_WARN_ON_ONCE_FOLIO(!folio_test_large(folio), folio);
        return -EINVAL;
 }
 static inline int split_huge_page(struct page *page)
 {
+       struct folio *folio = page_folio(page);
+
+       VM_WARN_ON_ONCE_FOLIO(!folio_test_large(folio), folio);
        return -EINVAL;
 }

 static inline int split_folio_to_list(struct folio *folio, struct list_head *list)
 {
+       VM_WARN_ON_ONCE_FOLIO(!folio_test_large(folio), folio);
        return -EINVAL;
 }

 static inline int try_folio_split(struct folio *folio, struct page *page,
                struct list_head *list)
 {
+       VM_WARN_ON_ONCE_FOLIO(!folio_test_large(folio), folio);
        return -EINVAL;
 }

--
Pankaj