-Wattribute-warning in drivers/base/arch_numa.c on RISC-V with CONFIG_NR_CPUS > 64

[nathanchance]

Debian recently bumped CONFIG_NR_CPUS from 64 to 128, which causes an instance of -Wattribute-warning from the fortify routines when CONFIG_UBSAN_BOUNDS is enabled. I have reduced this down to:

$ cat arch/riscv/configs/repro.config
CONFIG_FORTIFY_SOURCE=y
CONFIG_NR_CPUS=128
CONFIG_NUMA=y
CONFIG_UBSAN=y

$ make -skj"$(nproc)" ARCH=riscv LLVM=1 mrproper defconfig repro.config drivers/base/arch_numa.o
In file included from drivers/base/arch_numa.c:11:
In file included from include/linux/acpi.h:14:
In file included from include/linux/resource_ext.h:11:
In file included from include/linux/slab.h:17:
In file included from include/linux/gfp.h:7:
In file included from include/linux/mmzone.h:8:
In file included from include/linux/spinlock.h:63:
In file included from include/linux/lockdep.h:14:
In file included from include/linux/smp.h:13:
In file included from include/linux/cpumask.h:11:
In file included from include/linux/bitmap.h:13:
In file included from include/linux/string.h:383:
include/linux/fortify-string.h:430:4: warning: call to '__write_overflow_field' declared with 'warning' attribute: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Wattribute-warning]
  430 |                         __write_overflow_field(p_size_field, size);
      |                         ^
include/linux/fortify-string.h:430:4: note: called by function 'fortify_memset_chk(unsigned long, unsigned long, unsigned long)'
include/linux/bitmap.h:245:3: note: inlined by function 'cpumask_clear'
  245 |                 memset(dst, 0, len);
      |                 ^
include/linux/fortify-string.h:462:25: note: expanded from macro 'memset'
  462 | #define memset(p, c, s) __fortify_memset_chk(p, c, s,                   \
      |                         ^
include/linux/fortify-string.h:453:2: note: expanded from macro '__fortify_memset_chk'
  453 |         fortify_memset_chk(__fortify_size, p_size, p_size_field),       \
      |         ^
drivers/base/arch_numa.c:111:3: note: inlined by function 'setup_node_to_cpumask_map'
  111 |                 cpumask_clear(node_to_cpumask_map[node]);
      |                 ^
include/linux/fortify-string.h:430:4: note: use '-gline-directives-only' (implied by '-g1') or higher for more accurate inlining chain locations
  430 |                         __write_overflow_field(p_size_field, size);
      |                         ^
1 warning generated.

It reproduces with CONFIG_NR_CPUS=65, so 64 seems to be the limit where there is no warning. I do not see this warning with GCC 16.1.0, even with adding -Warray-bounds via CFLAGS_arch_numa.o.

I have tried to follow through the code to see what is going on here but I have not had much luck at this point so I'll double back later unless someone else beats me to it.

cc @kees

[nickdesaulniers]

include/linux/fortify-string.h:430:4: note: use '-gline-directives-only' (implied by '-g1') or higher for more accurate inlining chain locations

Does enabling CONFIG_DEBUG give more info to this trace? (Good job landing support for that @JustinStitt )

[nathanchance]

No, I don't think it does.

In file included from drivers/base/arch_numa.c:11:
In file included from include/linux/acpi.h:14:
In file included from include/linux/resource_ext.h:11:
In file included from include/linux/slab.h:17:
In file included from include/linux/gfp.h:7:
In file included from include/linux/mmzone.h:8:
In file included from include/linux/spinlock.h:63:
In file included from include/linux/lockdep.h:14:
In file included from include/linux/smp.h:13:
In file included from include/linux/cpumask.h:11:
In file included from include/linux/bitmap.h:13:
In file included from include/linux/string.h:383:
include/linux/fortify-string.h:430:4: warning: call to '__write_overflow_field' declared with 'warning' attribute: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Wattribute-warning]
  430 |                         __write_overflow_field(p_size_field, size);
      |                         ^
include/linux/fortify-string.h:430:4: note: called by function 'fortify_memset_chk'
include/linux/fortify-string.h:430:4: note: inlined by function 'bitmap_zero'
include/linux/fortify-string.h:430:4: note: inlined by function 'cpumask_clear'
include/linux/fortify-string.h:430:4: note: inlined by function 'setup_node_to_cpumask_map'

[nathanchance]

I should also note that this appears to happen with the default CONFIG_NODES_SHIFT of 2.

[nathanchance]

I have extracted a standalone reproducer for this:

https://godbolt.org/z/P6qre4TdT

I think this might be a loop unrolling issue, where clang unrolls the loop past the end of the array, which then triggers the fortify checks because the result of __builtin_dynamic_object_size will be the invalid memory from the final access. If I add either

#pragma clang loop unroll(disable)

before the for loop or

#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))
    if (nr_node_ids > ARRAY_SIZE(node_to_cpumask_map))
        return;

between the if statement and for loop, the problem disappears. Not sure if either of those would be acceptable upstream...

[nickdesaulniers]

How about clamping the value of node always be less than MAX_NUMNODES explicitly? Does this work?

diff --git a/drivers/base/arch_numa.c b/drivers/base/arch_numa.c
index c99f2ab105e5..06e3be0cc80b 100644
--- a/drivers/base/arch_numa.c
+++ b/drivers/base/arch_numa.c
@@ -106,7 +106,7 @@ static void __init setup_node_to_cpumask_map(void)
                setup_nr_node_ids();
 
        /* allocate and clear the mapping */
-       for (node = 0; node < nr_node_ids; node++) {
+       for (node = 0; node < nr_node_ids && node < MAX_NUMNODES; node++) {
                alloc_bootmem_cpumask_var(&node_to_cpumask_map[node]);
                cpumask_clear(node_to_cpumask_map[node]);
        }

[nathanchance]

Yes, that would work as well (I actually tested it this morning). I had figured that doing one check before the for loop would be more efficient so I also tested

diff --git a/drivers/base/arch_numa.c b/drivers/base/arch_numa.c
index 6476227b772c..f6a40ca0cedd 100644
--- a/drivers/base/arch_numa.c
+++ b/drivers/base/arch_numa.c
@@ -105,6 +105,9 @@ static void __init setup_node_to_cpumask_map(void)
        if (nr_node_ids == MAX_NUMNODES)
                setup_nr_node_ids();

+       if (nr_node_ids > MAX_NUMNODES)
+               return;
+
        /* allocate and clear the mapping */
        for (node = 0; node < nr_node_ids; node++) {
                alloc_bootmem_cpumask_var(&node_to_cpumask_map[node]);

but I am guessing it probably won't matter if the loop is going to be unrolled anyways.

[nickdesaulniers]

That would leave nodes < nr_node_ids un-allocated and the corresponding CPU mask not cleared. Perhaps email the author of the code about this and ask if nr_node_ids > MAX_NUMNODES is an anomalous condition that should be flagged elsewhere/else-how, or if one of the two above diffs is preferable?

[nathanchance]

I sent https://lore.kernel.org/20260811-arch_numa-avoid-fortify-warning-v1-1-59ce3e689f3a@kernel.org/ to start discussion about this upstream.