[RFC PATCH 0/3] folio->mapping == NULL check issue

[Zi Yan <ziy@nvidia.com>]

Hi all,

Based on Wei's observation[1], this patchset is trying to solve several
potential issues:
1. Patch 1, 2: dereferencing NULL folio->mapping in
   try_folio_split_to_order() for future users,
2. Patch 3: improper handling of negative return value of
   min_order_for_split() in mm/memory-failure.c

No bug is present for the existing code.

For 1, try_folio_split_to_order() is used in
truncate_inode_partial_folio() and it is fine since folio->mapping is
always not NULL there.

For 2, mm/memory-failure.c code does not check for -EBUSY return value of
min_order_for_split() and directly passes it to a folio split function.
The code works by accident but needs to be fixed.

folio_split_supported() does not check if folio->mapping is NULL, but
can dereference it in some cases. My current fix is adding a kernel-doc
to clarify this requirement. An alternative is to add folio->mapping
check and return -EBUSY and return -EINVAL for the other checks. But
folio_split_supported() will no longer checks for "supported",
folio_split_can_split() might be a better name. Then, the existing
can_split_folio() might better be renamed to
folio_split_refcount_check(). In addition, try_folio_split_to_order(),
which calls folio_split_supported(), might want to handle -EBUSY separately
to avoid calling split_huge_page_to_order() when the folio is truncated
for a known -EBUSY error.

Let me know your thoughts. Thanks.

Link: https://lore.kernel.org/all/20251120004735.52z7r4xmogw7mbsj@master/ [1]

Zi Yan (3):
  mm/huge_memory: prevent NULL pointer dereference in
    try_folio_split_to_order()
  mm/huge_memory: add kernel-doc for folio_split_supported()
  mm/memory-failure: handle min_order_for_split() error code properly

 include/linux/huge_mm.h |  7 +++++++
 mm/huge_memory.c        | 17 +++++++++++++++++
 mm/memory-failure.c     |  8 ++++++--
 3 files changed, 30 insertions(+), 2 deletions(-)

-- 
2.51.0