From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5D7B01D555 for ; Sat, 22 Nov 2025 22:02:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763848938; cv=none; b=HlmCe/SSlBV7aDjfj/PDUrzUgHvZ+Xmznx373j3EaPwWqGKLEP0YihVJZEUn0BrbkjzdWqW7Xc/pQzmx48OQtAJajG0dZszqb8sRzwt6hRwiL+HJIPnf/a/EMpVCSYyzPOSZHHtMjmmVD99j2kAHSasJlLwewOEfO4oyEdxHKzM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763848938; c=relaxed/simple; bh=CpvK8MOMQVGXRJJ+3abhsqh+28Bc8/ZW6Q+RP/itIpU=; h=Date:To:From:Subject:Message-Id; b=gU8ETEZgdNsbrdf6mqgynJ2eoukV/8XCkbxVX9f+11JqCrSv49A+T7gwfFYYYbKZY1TeBjN34YC+2yuRwhho0FjxQxJ17ibZo4XPPFDt6yee21qF4aZK8jzGUSWQngmgZZP/Qhch/EERTMSCmWtC7S4tUYlefOPAfvec7VZYLTc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=BAEIQafr; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="BAEIQafr" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8903EC4CEF5; Sat, 22 Nov 2025 22:02:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1763848937; bh=CpvK8MOMQVGXRJJ+3abhsqh+28Bc8/ZW6Q+RP/itIpU=; h=Date:To:From:Subject:From; b=BAEIQafr8BqtIzVg6YhyPzQ6SQbhrOzgaaSo6sIk+wWW5bWUcF3i9dWY1xow0EZRl hkmRfgFBQxyZ3PX2eZyrxi6ORla1ppV85sQLu7FupOvnntHhUCH3oF0f/ALSYQ6JWl E5VXxrwDhE5xSTb7om8DzHpLorz5rdSJC59GJ6Tk= Date: Sat, 22 Nov 2025 14:02:17 -0800 To: mm-commits@vger.kernel.org,ryan.roberts@arm.com,richard.weiyang@gmail.com,npache@redhat.com,nao.horiguchi@gmail.com,lorenzo.stoakes@oracle.com,linmiaohe@huawei.com,liam.howlett@oracle.com,lance.yang@linux.dev,dev.jain@arm.com,david@kernel.org,baolin.wang@linux.alibaba.com,baohua@kernel.org,balbirs@nvidia.com,ziy@nvidia.com,akpm@linux-foundation.org From: Andrew Morton Subject: + mm-huge_memory-make-min_order_for_split-always-return-an-order.patch added to mm-new branch Message-Id: <20251122220217.8903EC4CEF5@smtp.kernel.org> Precedence: bulk X-Mailing-List: mm-commits@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: The patch titled Subject: mm/huge_memory: make min_order_for_split() always return an order has been added to the -mm mm-new branch. Its filename is mm-huge_memory-make-min_order_for_split-always-return-an-order.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/mm-huge_memory-make-min_order_for_split-always-return-an-order.patch This patch will later appear in the mm-new branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Note, mm-new is a provisional staging ground for work-in-progress patches, and acceptance into mm-new is a notification for others take notice and to finish up reviews. Please do not hesitate to respond to review feedback and post updated versions to replace or incrementally fixup patches in mm-new. Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Zi Yan Subject: mm/huge_memory: make min_order_for_split() always return an order Date: Fri, 21 Nov 2025 21:55:28 -0500 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 new_order is unsigned int in __folio_split() and this large new_order is rejected as an invalid input. The code does not cause a bug. soft_offline_in_use_page() also uses min_order_for_split() but it always passes 0 as new_order for split. Fix it by making min_order_for_split() always return an order. When the given folio is truncated, namely folio->mapping == NULL, return 0 and let a subsequent split function handle the situation and return -EBUSY. Add kernel-doc to min_order_for_split() to clarify its use. Link: https://lkml.kernel.org/r/20251122025529.1562592-4-ziy@nvidia.com Signed-off-by: Zi Yan Cc: Balbir Singh Cc: Baolin Wang Cc: Barry Song Cc: David Hildenbrand (Red Hat) Cc: Dev Jain Cc: Lance Yang Cc: Liam Howlett Cc: Lorenzo Stoakes Cc: Miaohe Lin Cc: Naoya Horiguchi Cc: Nico Pache Cc: Ryan Roberts Cc: Wei Yang Signed-off-by: Andrew Morton --- include/linux/huge_mm.h | 6 +++--- mm/huge_memory.c | 25 +++++++++++++++++++------ 2 files changed, 22 insertions(+), 9 deletions(-) --- a/include/linux/huge_mm.h~mm-huge_memory-make-min_order_for_split-always-return-an-order +++ a/include/linux/huge_mm.h @@ -372,7 +372,7 @@ enum split_type { 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); int folio_check_splittable(struct folio *folio, unsigned int new_order, enum split_type split_type, bool warns); @@ -634,10 +634,10 @@ static inline int split_huge_page(struct return -EINVAL; } -static inline int min_order_for_split(struct folio *folio) +static inline unsigned int min_order_for_split(struct folio *folio) { VM_WARN_ON_ONCE_FOLIO(1, folio); - return -EINVAL; + return 0; } static inline int split_folio_to_list(struct folio *folio, struct list_head *list) --- a/mm/huge_memory.c~mm-huge_memory-make-min_order_for_split-always-return-an-order +++ a/mm/huge_memory.c @@ -4230,16 +4230,29 @@ int folio_split(struct folio *folio, uns 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. + * If a file-backed folio is truncated, 0 will be returned. Any subsequent + * split attempt should get -EBUSY from split checking code. + * + * Return: @folio's minimum order for split + */ +unsigned int min_order_for_split(struct folio *folio) { if (folio_test_anon(folio)) return 0; - if (!folio->mapping) { - if (folio_test_pmd_mappable(folio)) - count_vm_event(THP_SPLIT_PAGE_FAILED); - return -EBUSY; - } + /* + * 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) + return 0; return mapping_min_folio_order(folio->mapping); } _ Patches currently in -mm which might be from ziy@nvidia.com are mm-huge_memory-add-split_huge_page_to_order.patch mm-memory-failure-improve-large-block-size-folio-handling.patch mm-huge_memory-fix-kernel-doc-comments-for-folio_split-and-related.patch mm-huge_memory-fix-kernel-doc-comments-for-folio_split-and-related-fix.patch mm-huge_memory-fix-kernel-doc-comments-for-folio_split-and-related-fix-2.patch mm-huge_memory-change-folio_split_supported-to-folio_check_splittable.patch mm-huge_memory-replace-can_split_folio-with-direct-refcount-calculation.patch mm-huge_memory-make-min_order_for_split-always-return-an-order.patch mm-huge_memory-fix-folio-split-stats-counting.patch