linux-kernel - Re: [RFC PATCH 3/3] mm/memory-failure: handle min_order_for

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: <03B7D3C4-F954-4CF1-9585-38D4E5B113E4@nvidia.com>
Date: Thu, 20 Nov 2025 09:59:23 -0500
From: Zi Yan <ziy@...dia.com>
To: "David Hildenbrand (Red Hat)" <david@...nel.org>
Cc: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
 Andrew Morton <akpm@...ux-foundation.org>,
 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>,
 Miaohe Lin <linmiaohe@...wei.com>, Naoya Horiguchi <nao.horiguchi@...il.com>,
 linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 3/3] mm/memory-failure: handle min_order_for_split()
 error code properly

On 20 Nov 2025, at 4:37, David Hildenbrand (Red Hat) wrote:

> On 11/20/25 04:59, Zi Yan wrote:
>> min_order_for_split() returns -EBUSY when the folio is truncated and cannot
>> be split. In commit 77008e1b2ef7 ("mm/huge_memory: do not change
>> split_huge_page*() target order silently"), memory_failure() does not
>> handle it and pass -EBUSY to try_to_split_thp_page() directly.
>> try_to_split_thp_page() returns -EINVAL since -EBUSY becomes 0xfffffff0 as
>
> I'm wondering whether we should change min_order_for_split() to something like:
>
>
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index 7c69572b6c3f5..34eb6fec9a059 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -4210,16 +4210,19 @@ int folio_split(struct folio *folio, unsigned int new_order,
>                              SPLIT_TYPE_NON_UNIFORM);
>  }
>  -int min_order_for_split(struct folio *folio)
> +unsigned int min_order_for_split(struct folio *folio)
>  {
>         if (folio_test_anon(folio))
>                 return 0;
>  +       /*
> +        * If the folio got truncated, we don't know the previous mapping and
> +        * consequently the old min order. But it doesn't matter, as any split
> +        * attempt will immediately fail with -EBUSY as the folio cannot get
> +        * split until freed.
> +        */
>         if (!folio->mapping) {
> -               if (folio_test_pmd_mappable(folio))
> -                       count_vm_event(THP_SPLIT_PAGE_FAILED);
> -               return -EBUSY;
> -       }
> +               return 0;
>          return mapping_min_folio_order(folio->mapping);
>  }

I thought about it. My concern was that what if the returned order is not
immediately used for split, maybe for some calculation. I might think too much.
Your approach is much simpler.

I am also going to add a kernel-doc and change the return type to unsigned int:

diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
index 0d55354e3a34..e0731e01df27 100644
--- a/include/linux/huge_mm.h
+++ b/include/linux/huge_mm.h
@@ -373,7 +373,7 @@ bool can_split_folio(struct folio *folio, int caller_pins, int *pextra_pins);
 int __split_huge_page_to_list_to_order(struct page *page, struct list_head *list,
                unsigned int new_order);
 int folio_split_unmapped(struct folio *folio, unsigned int new_order);
-int min_order_for_split(struct folio *folio);
+unsigned int min_order_for_split(struct folio *folio);
 int split_folio_to_list(struct folio *folio, struct list_head *list);
 bool folio_split_supported(struct folio *folio, unsigned int new_order,
                enum split_type split_type, bool warns);
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 23239c19b36e..f45560b53210 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -4238,7 +4238,18 @@ int folio_split(struct folio *folio, unsigned int new_order,
                             SPLIT_TYPE_NON_UNIFORM);
 }

-int min_order_for_split(struct folio *folio)
+/**
+ * min_order_for_split() - get the minimum order @folio can be split to
+ * @folio: folio to split
+ *
+ * min_order_for_split() tells the minimum order @folio can be split to.
+ * Anonymous folios can be split to order 0, file-backed folios might have
+ * limitations at file system level. If the folio is truncated, 0 will be
+ * returned and any split attempt will get -EBUSY.
+ *
+ * Return: @folio's minimum order
+ */
+unsigned int min_order_for_split(struct folio *folio)
 {
        if (folio_test_anon(folio))
                return 0;

Best Regards,
Yan, Zi