linux-kernel - Re: [PATCH 1/2] mm/huge_memory: do not change split_huge

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: <11b98453-560d-4c55-8ac9-43d1cf7b3543@linux.dev>
Date: Sat, 11 Oct 2025 10:25:57 +0800
From: Lance Yang <lance.yang@...ux.dev>
To: Zi Yan <ziy@...dia.com>
Cc: akpm@...ux-foundation.org, syzkaller-bugs@...glegroups.com,
 mcgrof@...nel.org, nao.horiguchi@...il.com,
 Lorenzo Stoakes <lorenzo.stoakes@...cle.com>, kernel@...kajraghav.com,
 Baolin Wang <baolin.wang@...ux.alibaba.com>,
 "Liam R. Howlett" <Liam.Howlett@...cle.com>, Nico Pache <npache@...hat.com>,
 Ryan Roberts <ryan.roberts@....com>, jane.chu@...cle.com,
 Dev Jain <dev.jain@....com>, Barry Song <baohua@...nel.org>,
 "Matthew Wilcox (Oracle)" <willy@...radead.org>,
 linux-fsdevel@...r.kernel.org, david@...hat.com,
 linux-kernel@...r.kernel.org, linux-mm@...ck.org, linmiaohe@...wei.com,
 syzbot+e6367ea2fdab6ed46056@...kaller.appspotmail.com
Subject: Re: [PATCH 1/2] mm/huge_memory: do not change split_huge_page*()
 target order silently.

On 2025/10/11 01:39, Zi Yan wrote:
> Page cache folios from a file system that support large block size (LBS)
> can have minimal folio order greater than 0, thus a high order folio might
> not be able to be split down to order-0. Commit e220917fa507 ("mm: split a
> folio in minimum folio order chunks") bumps the target order of
> split_huge_page*() to the minimum allowed order when splitting a LBS folio.
> This causes confusion for some split_huge_page*() callers like memory
> failure handling code, since they expect after-split folios all have
> order-0 when split succeeds but in really get min_order_for_split() order
> folios.
> 
> Fix it by failing a split if the folio cannot be split to the target order.
> 
> Fixes: e220917fa507 ("mm: split a folio in minimum folio order chunks")
> [The test poisons LBS folios, which cannot be split to order-0 folios, and
> also tries to poison all memory. The non split LBS folios take more memory
> than the test anticipated, leading to OOM. The patch fixed the kernel
> warning and the test needs some change to avoid OOM.]
> Reported-by: syzbot+e6367ea2fdab6ed46056@...kaller.appspotmail.com
> Closes: https://lore.kernel.org/all/68d2c943.a70a0220.1b52b.02b3.GAE@google.com/
> Signed-off-by: Zi Yan <ziy@...dia.com>
> ---
>   include/linux/huge_mm.h | 28 +++++-----------------------
>   mm/huge_memory.c        |  9 +--------
>   mm/truncate.c           |  6 ++++--
>   3 files changed, 10 insertions(+), 33 deletions(-)
> 
> diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
> index 8eec7a2a977b..9950cda1526a 100644
> --- a/include/linux/huge_mm.h
> +++ b/include/linux/huge_mm.h
> @@ -394,34 +394,16 @@ static inline int split_huge_page_to_list_to_order(struct page *page, struct lis
>    * Return: 0: split is successful, otherwise split failed.
>    */
>   static inline int try_folio_split(struct folio *folio, struct page *page,
> -		struct list_head *list)
> +		struct list_head *list, unsigned int order)

Seems like we need to add the order parameter to the stub for 
try_folio_split() as well?

#ifdef CONFIG_TRANSPARENT_HUGEPAGE

...

#else /* CONFIG_TRANSPARENT_HUGEPAGE */

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

#endif /* CONFIG_TRANSPARENT_HUGEPAGE */

Cheers,
Lance