[PATCH 1/2] x86/mm: support memory-failure on 32-bits with SPARSEMEM

[PATCH 1/2] x86/mm: support memory-failure on 32-bits with SPARSEMEM

[Xie Yuanbin]

The historical commit d949f36f1865c60239d4 ("x86: Fix hwpoison code
related build failure on 32-bit NUMAQ"), disabled x86_32's
memory-failure when SPARSEMEM is enabled, because the number of
page-flags are insufficient.

The commit 09022bc196d23484a7a5 ("mm: remove PG_error") removes a
page flag, so memory-failure can now be enable now.

Signed-off-by: Xie Yuanbin <xieyuanbin1@huawei.com>
---
 arch/x86/Kconfig | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index d55c01efd7c2..f9ee57a55500 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -750,13 +750,10 @@ config IOSF_MBI_DEBUG
 
 config X86_SUPPORTS_MEMORY_FAILURE
 	def_bool y
 	# MCE code calls memory_failure():
 	depends on X86_MCE
-	# On 32-bit this adds too big of NODES_SHIFT and we run out of page flags:
-	# On 32-bit SPARSEMEM adds too big of SECTIONS_WIDTH:
-	depends on X86_64 || !SPARSEMEM
 	select ARCH_SUPPORTS_MEMORY_FAILURE
 
 config X86_32_IRIS
 	tristate "Eurobraille/Iris poweroff module"
 	depends on X86_32
-- 
2.51.0

[PATCH 2/2] mm/memory-failure: remove the selection of RAS

[Xie Yuanbin]

The commit 97f0b13452198290799f ("tracing: add trace event for
memory-failure") introduces the selection of RAS in memory-failure.
This commit is just a tracing feature; in reality, there is no dependency
between memory-failure and RAS. RAS increases the size of the bzImage
image by 8k, which is very valuable for embedded devices.

Signed-off-by: Xie Yuanbin <xieyuanbin1@huawei.com>
---
 mm/Kconfig          | 1 -
 mm/memory-failure.c | 2 ++
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/mm/Kconfig b/mm/Kconfig
index a5a90b169435..c3a8e0ba1ac1 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -738,11 +738,10 @@ config ARCH_SUPPORTS_MEMORY_FAILURE
 
 config MEMORY_FAILURE
 	depends on MMU
 	depends on ARCH_SUPPORTS_MEMORY_FAILURE
 	bool "Enable recovery from hardware memory errors"
-	select RAS
 	help
 	  Enables code to recover from some memory failures on systems
 	  with MCA recovery. This allows a system to continue running
 	  even when some of its memory has uncorrected errors. This requires
 	  special hardware support and typically ECC memory.
diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index f698df156bf8..baf2bd79b2fb 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -1276,11 +1276,13 @@ static void update_per_node_mf_stats(unsigned long pfn,
  * setting PG_dirty outside page lock. See also comment above set_page_dirty().
  */
 static int action_result(unsigned long pfn, enum mf_action_page_type type,
 			 enum mf_result result)
 {
+#ifdef CONFIG_RAS
 	trace_memory_failure_event(pfn, type, result);
+#endif
 
 	if (type != MF_MSG_ALREADY_POISONED) {
 		num_poisoned_pages_inc(pfn);
 		update_per_node_mf_stats(pfn, result);
 	}
-- 
2.51.0

Re: [PATCH 2/2] mm/memory-failure: remove the selection of RAS

[David Hildenbrand]

On 03.11.25 04:35, Xie Yuanbin wrote:
> The commit 97f0b13452198290799f ("tracing: add trace event for
> memory-failure") introduces the selection of RAS in memory-failure.
> This commit is just a tracing feature; in reality, there is no dependency
> between memory-failure and RAS. RAS increases the size of the bzImage
> image by 8k, which is very valuable for embedded devices.
> 
> Signed-off-by: Xie Yuanbin <xieyuanbin1@huawei.com>
> ---
>   mm/Kconfig          | 1 -
>   mm/memory-failure.c | 2 ++
>   2 files changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/mm/Kconfig b/mm/Kconfig
> index a5a90b169435..c3a8e0ba1ac1 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -738,11 +738,10 @@ config ARCH_SUPPORTS_MEMORY_FAILURE
>   
>   config MEMORY_FAILURE
>   	depends on MMU
>   	depends on ARCH_SUPPORTS_MEMORY_FAILURE
>   	bool "Enable recovery from hardware memory errors"
> -	select RAS
>   	help
>   	  Enables code to recover from some memory failures on systems
>   	  with MCA recovery. This allows a system to continue running
>   	  even when some of its memory has uncorrected errors. This requires
>   	  special hardware support and typically ECC memory.
> diff --git a/mm/memory-failure.c b/mm/memory-failure.c
> index f698df156bf8..baf2bd79b2fb 100644
> --- a/mm/memory-failure.c
> +++ b/mm/memory-failure.c
> @@ -1276,11 +1276,13 @@ static void update_per_node_mf_stats(unsigned long pfn,
>    * setting PG_dirty outside page lock. See also comment above set_page_dirty().
>    */
>   static int action_result(unsigned long pfn, enum mf_action_page_type type,
>   			 enum mf_result result)
>   {
> +#ifdef CONFIG_RAS
>   	trace_memory_failure_event(pfn, type, result);
> +#endif
>   
>   	if (type != MF_MSG_ALREADY_POISONED) {
>   		num_poisoned_pages_inc(pfn);
>   		update_per_node_mf_stats(pfn, result);
>   	}

I rather wonder whether the memory-tracing code should live in a 
memory-failure.h instead.

-- 
Cheers

David / dhildenb

Re: [PATCH 2/2] mm/memory-failure: remove the selection of RAS

[Borislav Petkov]

On Mon, Nov 03, 2025 at 01:15:58PM +0100, David Hildenbrand wrote:
> I rather wonder whether the memory-tracing code should live in a
> memory-failure.h instead.

Yah, move it pls. It doesn't belong there.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH 1/2] x86/mm: support memory-failure on 32-bits with SPARSEMEM

[Xie Yuanbin]

On Mon, 3 Nov 2025 13:39:20 +0100, Borislav Petkov wrote:
>On Mon, Nov 03, 2025 at 01:15:58PM +0100, David Hildenbrand wrote:
>> I rather wonder whether the memory-tracing code should live in a
>> memory-failure.h instead.
>
> Yah, move it pls. It doesn't belong there.

Okay, I will try it in V2 patches.

I'm not very familiar with the implementation of trace.
A trace/events/memory-failure.h file should be added, and:
```c
#define CREATE_TRACE_POINTS
#include <trace/events/memory-failure.h>
```
should be added in memory-failure.c, right?

If I have made any mistakes, please point them out. Thanks!

Xie Yuanbin

Re: [PATCH 1/2] x86/mm: support memory-failure on 32-bits with SPARSEMEM

[David Hildenbrand]

On 03.11.25 04:35, Xie Yuanbin wrote:
> The historical commit d949f36f1865c60239d4 ("x86: Fix hwpoison code
> related build failure on 32-bit NUMAQ"), disabled x86_32's
> memory-failure when SPARSEMEM is enabled, because the number of
> page-flags are insufficient.
> 
> The commit 09022bc196d23484a7a5 ("mm: remove PG_error") removes a
> page flag, so memory-failure can now be enable now.

In the meantime, we added PG_dropbehind

-- 
Cheers

David / dhildenb

Re: [PATCH 1/2] x86/mm: support memory-failure on 32-bits with SPARSEMEM

[Xie Yuanbin]

On Mon, 3 Nov 2025 13:08:38 +0100, David Hildenbrand wrote:
>> The historical commit d949f36f1865c60239d4 ("x86: Fix hwpoison code
>> related build failure on 32-bit NUMAQ"), disabled x86_32's
>> memory-failure when SPARSEMEM is enabled, because the number of
>> page-flags are insufficient.
>> 
>> The commit 09022bc196d23484a7a5 ("mm: remove PG_error") removes a
>> page flag, so memory-failure can now be enable now.
>
> In the meantime, we added PG_dropbehind

Okay, I completely understand now.

For historical versions, MEMORY_FAILURE cannot be enabled with x86_32 &&
SPARSEMEM because the number of page-flags are insufficient. At least it
has been so from 5.10.x to 6.9.x.

The commit 46df8e73a4a3f1445f2a ("mm: free up PG_slab") from 6.10-rc1
remove a flag that allows MEMORY_FAILURE to be enabled from here on.

The commit 09022bc196d23484a7a5 ("mm: remove PG_error") from 6.12-rc1
remove another flag.

The commit cceba6f7e46c48deca43 ("mm: add PG_dropbehind folio flag") from
6.14-rc1 add a flag, but MEMORY_FAILURE can still be enabled.

At least for the current version, memory-failure can be safely enabled.
The number of pageflags reaches its maximum value under the following
conditions: HIGHMEM && SPARSEMEM && X86_PAE && X86_PAT. In this case, if
MEMORY_FAILURE is enabled, the number of pageflags just reached the limit
of 32.

I will update the V2 patch to describe it.

> Cheers
>
> David / dhildenb

Thanks!

Xie Yuanbin

Re: [PATCH 1/2] x86/mm: support memory-failure on 32-bits with SPARSEMEM

[Dave Hansen]

On 11/3/25 05:23, Xie Yuanbin wrote:
> I will update the V2 patch to describe it.

Please also include the logic behind why you want this change, including
a description of the hardware on which you want to use this change.