linux-kernel - [PATCH v2 0/3] Do not change split folio target order

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-next>] [day] [month] [year] [list]

Message-ID: <20251016033452.125479-1-ziy@nvidia.com>
Date: Wed, 15 Oct 2025 23:34:49 -0400
From: Zi Yan <ziy@...dia.com>
To: linmiaohe@...wei.com,
	david@...hat.com,
	jane.chu@...cle.com,
	kernel@...kajraghav.com,
	syzbot+e6367ea2fdab6ed46056@...kaller.appspotmail.com,
	syzkaller-bugs@...glegroups.com
Cc: ziy@...dia.com,
	akpm@...ux-foundation.org,
	mcgrof@...nel.org,
	nao.horiguchi@...il.com,
	Lorenzo Stoakes <lorenzo.stoakes@...cle.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>,
	Dev Jain <dev.jain@....com>,
	Barry Song <baohua@...nel.org>,
	Lance Yang <lance.yang@...ux.dev>,
	"Matthew Wilcox (Oracle)" <willy@...radead.org>,
	Wei Yang <richard.weiyang@...il.com>,
	linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	linux-mm@...ck.org
Subject: [PATCH v2 0/3] Do not change split folio target order

Hi all,

Currently, huge page and large folio split APIs would bump new order
when the target folio has min_order_for_split() > 0 and return
success if split succeeds. When callers expect after-split folios to be
order-0, the actual ones are not. The callers might not be able to
handle them, since they call huge page and large folio split APIs to get
order-0 folios. This issue appears in a recent report on
memory_failure()[1], where memory_failure() used split_huge_page() to split
a large forlio to order-0, but after a successful split got non order-0
folios. Because memory_failure() can only handle order-0 folios, this
caused a WARNING.

Fix the issue by not changing split target order and failing the
split if min_order_for_split() is greater than the target order.
In addition, to avoid wasting memory in memory failure handling, a second
patch is added to always split a large folio to min_order_for_split()
even if it is not 0, so that folios not containing the poisoned page can
be freed for reuse. For soft offline, since the folio is still accessible,
do not split if min_order_for_split() is not zero to avoid potential
performance loss.

Changelog
===
>From V1[2]:
1. Fixed !CONFIG_TRANSPARENT_HUGEPAGE version of try_folio_split()
signature.
2. Updated the comment of try_folio_split().
3. Renamed try_folio_split() to try_folio_split_to_order().
4. Removed unused list parameter from try_folio_split_to_order().
5. Added information on min_order_for_split() in
try_folio_split_to_order()'s comment.
6. Added a comment on non_uniform_split_supported() caller on
warns=false.
7. Added min_order_for_split() to !CONFIG_TRANSPARENT_HUGEPAGE.
8. Fixed kernel-doc comment format for try_folio_split_to_order(), folio_split,
__folio_split(), and __split_unmapped_folio().

Link: https://lore.kernel.org/all/68d2c943.a70a0220.1b52b.02b3.GAE@google.com/ [1]
Link: https://lore.kernel.org/linux-mm/20251010173906.3128789-2-ziy@nvidia.com/ [2]

Zi Yan (3):
  mm/huge_memory: do not change split_huge_page*() target order
    silently.
  mm/memory-failure: improve large block size folio handling.
  mm/huge_memory: fix kernel-doc comments for folio_split() and related.

 include/linux/huge_mm.h | 61 ++++++++++++++++++-----------------------
 mm/huge_memory.c        | 36 +++++++++++-------------
 mm/memory-failure.c     | 25 ++++++++++++++---
 mm/truncate.c           |  6 ++--
 4 files changed, 68 insertions(+), 60 deletions(-)

-- 
2.51.0