linux-kernel - Re: [PATCH] mm/memory-failure: reject unsupported non-folio compound page

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

Message-ID: <02a755d7-fc08-4b65-8f31-d45235596209@oracle.com>
Date: Fri, 6 Feb 2026 09:04:13 -0800
From: jane.chu@...cle.com
To: Miaohe Lin <linmiaohe@...wei.com>, akpm@...ux-foundation.org
Cc: nao.horiguchi@...il.com, ziy@...dia.com, shicenci@...il.com,
        david@...nel.org, linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mm/memory-failure: reject unsupported non-folio compound
 page


On 2/4/2026 11:53 PM, Miaohe Lin wrote:
> When !CONFIG_TRANSPARENT_HUGEPAGE, a non-folio compound page can appear in
> a userspace mapping via either vm_insert_*() functions or
> vm_operatios_struct->fault(). They are not folios, thus should not be
> considered for folio operations like split. To reject these pages, make
> sure get_hwpoison_page() is always called as HWPoisonHandlable() will do
> the right work.
> 
> Fixes: 689b8986776c ("mm/memory-failure: improve large block size folio handling")
> Reported-by: 是参差 <shicenci@...il.com>
> Closes: https://lore.kernel.org/all/PS1PPF7E1D7501F1E4F4441E7ECD056DEADAB98A@PS1PPF7E1D7501F.apcprd02.prod.outlook.com/
> Reviewed-by: Zi Yan <ziy@...dia.com>
> Tested-by: Zi Yan <ziy@...dia.com>
> Signed-off-by: Miaohe Lin <linmiaohe@...wei.com>
> [Some commit log borrowed from Zi Yan <ziy@...dia.com>. Thanks.]
> ---
>   mm/memory-failure.c | 42 ++++++++++++++++++++----------------------
>   1 file changed, 20 insertions(+), 22 deletions(-)
> 
> diff --git a/mm/memory-failure.c b/mm/memory-failure.c
> index 825c706ac576..ba4231858a36 100644
> --- a/mm/memory-failure.c
> +++ b/mm/memory-failure.c
> @@ -2411,31 +2411,29 @@ int memory_failure(unsigned long pfn, int flags)
>   	 * In fact it's dangerous to directly bump up page count from 0,
>   	 * that may make page_ref_freeze()/page_ref_unfreeze() mismatch.
>   	 */
> -	if (!(flags & MF_COUNT_INCREASED)) {
> -		res = get_hwpoison_page(p, flags);
> -		if (!res) {
> -			if (is_free_buddy_page(p)) {
> -				if (take_page_off_buddy(p)) {
> -					page_ref_inc(p);
> -					res = MF_RECOVERED;
> -				} else {
> -					/* We lost the race, try again */
> -					if (retry) {
> -						ClearPageHWPoison(p);
> -						retry = false;
> -						goto try_again;
> -					}
> -					res = MF_FAILED;
> -				}
> -				res = action_result(pfn, MF_MSG_BUDDY, res);
> +	res = get_hwpoison_page(p, flags);
> +	if (!res) {
> +		if (is_free_buddy_page(p)) {
> +			if (take_page_off_buddy(p)) {
> +				page_ref_inc(p);
> +				res = MF_RECOVERED;
>   			} else {
> -				res = action_result(pfn, MF_MSG_KERNEL_HIGH_ORDER, MF_IGNORED);
> +				/* We lost the race, try again */
> +				if (retry) {
> +					ClearPageHWPoison(p);
> +					retry = false;
> +					goto try_again;
> +				}
> +				res = MF_FAILED;
>   			}
> -			goto unlock_mutex;
> -		} else if (res < 0) {
> -			res = action_result(pfn, MF_MSG_GET_HWPOISON, MF_IGNORED);
> -			goto unlock_mutex;
> +			res = action_result(pfn, MF_MSG_BUDDY, res);
> +		} else {
> +			res = action_result(pfn, MF_MSG_KERNEL_HIGH_ORDER, MF_IGNORED);
>   		}
> +		goto unlock_mutex;
> +	} else if (res < 0) {
> +		res = action_result(pfn, MF_MSG_GET_HWPOISON, MF_IGNORED);
> +		goto unlock_mutex;
>   	}
>   
>   	folio = page_folio(p);

Look good.

Reviewed-by: Jane Chu <jane.chu@...cle.com>

-jane