From: Arnd Bergmann <arnd@arndb.de>

This driver fails build testing with larger values of CONFIG_NR_CPUS:

drivers/leds/trigger/ledtrig-cpu.c: In function ‘ledtrig_cpu_init’:
include/linux/compiler_types.h:571:45: error: call to ‘__compiletime_assert_726’ declared with attribute error: BUILD_BUG_ON failed: CONFIG_NR_CPUS > 9999
drivers/leds/trigger/ledtrig-cpu.c:137:9: note: in expansion of macro ‘BUILD_BUG_ON’
  137 |         BUILD_BUG_ON(CONFIG_NR_CPUS > 9999);

Enforce this limit in Kconfig instead to avoid the build failure.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/leds/trigger/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/leds/trigger/Kconfig b/drivers/leds/trigger/Kconfig
index c11282a74b5a..e07bd17cfe35 100644
--- a/drivers/leds/trigger/Kconfig
+++ b/drivers/leds/trigger/Kconfig
@@ -65,6 +65,7 @@ config LEDS_TRIGGER_BACKLIGHT
 config LEDS_TRIGGER_CPU
 	bool "LED CPU Trigger"
 	depends on !PREEMPT_RT
+	depends on NR_CPUS <= 9999
 	help
 	  This allows LEDs to be controlled by active CPUs. This shows
 	  the active CPUs across an array of LEDs so you can see which
-- 
2.39.5

On Fri, 20 Jun 2025, Arnd Bergmann wrote:

> From: Arnd Bergmann <arnd@arndb.de>
> 
> This driver fails build testing with larger values of CONFIG_NR_CPUS:
> 
> drivers/leds/trigger/ledtrig-cpu.c: In function ‘ledtrig_cpu_init’:
> include/linux/compiler_types.h:571:45: error: call to ‘__compiletime_assert_726’ declared with attribute error: BUILD_BUG_ON failed: CONFIG_NR_CPUS > 9999
> drivers/leds/trigger/ledtrig-cpu.c:137:9: note: in expansion of macro ‘BUILD_BUG_ON’
>   137 |         BUILD_BUG_ON(CONFIG_NR_CPUS > 9999);
> 
> Enforce this limit in Kconfig instead to avoid the build failure.

I have so many questions!

- This number seems arbitrary - what is the limiting factor?
  - Character size for printing?
- What platform did you test this on to blow through that number?
- What if we really do want 10000+ CPUs?
  - And what will that LED array look like to support them all?
- If we're enforcing here, is the BUILD_BUG_ON() now superfluous?

> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>  drivers/leds/trigger/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/leds/trigger/Kconfig b/drivers/leds/trigger/Kconfig
> index c11282a74b5a..e07bd17cfe35 100644
> --- a/drivers/leds/trigger/Kconfig
> +++ b/drivers/leds/trigger/Kconfig
> @@ -65,6 +65,7 @@ config LEDS_TRIGGER_BACKLIGHT
>  config LEDS_TRIGGER_CPU
>  	bool "LED CPU Trigger"
>  	depends on !PREEMPT_RT
> +	depends on NR_CPUS <= 9999
>  	help
>  	  This allows LEDs to be controlled by active CPUs. This shows
>  	  the active CPUs across an array of LEDs so you can see which
> -- 
> 2.39.5
> 

-- 
Lee Jones [李琼斯]

On Wed, Jun 25, 2025, at 11:24, Lee Jones wrote:
> On Fri, 20 Jun 2025, Arnd Bergmann wrote:
>> 
>> Enforce this limit in Kconfig instead to avoid the build failure.
>
> I have so many questions!
>
> - This number seems arbitrary - what is the limiting factor?
>   - Character size for printing?

That is my best guess, yes. The original commit 8f88731d052d
("led-triggers: create a trigger for CPU activity") already
had this, plus

#define MAX_NAME_LEN 8
snprintf(trig->name, MAX_NAME_LEN, "cpu%d", cpu);

which comes out to 10000 cpus (0 through 9999) in a NUL-terminated
string. Obviously we could have a higher limit here but would
technically still need to check that.

> - What platform did you test this on to blow through that number?

I was only compile-testing with a crazy number of CPUs, to see
what would break, in particular when there are per-cpu structures
or cpumask_t variables on the stack. I sent fixes for the ones
that broke the build, but don't expect anything to actually
need this at runtime. Some of the fixes I sent also address
possible stack overflows that happen with a more realistic
number of CPUs.

> - What if we really do want 10000+ CPUs?
>   - And what will that LED array look like to support them all?

abcc131292aa ("ledtrig-cpu: Limit to 8 CPUs") actually added a
runtime limit to eight CPUS, which is probably more reasonable.

> - If we're enforcing here, is the BUILD_BUG_ON() now superfluous?

Yes, but it documents the requirement better than just the
Kconfig dependency. Since there is a runtime limit, we could
probably just drop the compile-time check and not add the
Kconfig check.

      Arnd

On Wed, 25 Jun 2025, Arnd Bergmann wrote:

> On Wed, Jun 25, 2025, at 11:24, Lee Jones wrote:
> > On Fri, 20 Jun 2025, Arnd Bergmann wrote:
> >> 
> >> Enforce this limit in Kconfig instead to avoid the build failure.
> >
> > I have so many questions!
> >
> > - This number seems arbitrary - what is the limiting factor?
> >   - Character size for printing?
> 
> That is my best guess, yes. The original commit 8f88731d052d
> ("led-triggers: create a trigger for CPU activity") already
> had this, plus
> 
> #define MAX_NAME_LEN 8
> snprintf(trig->name, MAX_NAME_LEN, "cpu%d", cpu);
> 
> which comes out to 10000 cpus (0 through 9999) in a NUL-terminated
> string. Obviously we could have a higher limit here but would
> technically still need to check that.
> 
> > - What platform did you test this on to blow through that number?
> 
> I was only compile-testing with a crazy number of CPUs, to see
> what would break, in particular when there are per-cpu structures
> or cpumask_t variables on the stack. I sent fixes for the ones
> that broke the build, but don't expect anything to actually
> need this at runtime. Some of the fixes I sent also address
> possible stack overflows that happen with a more realistic
> number of CPUs.
> 
> > - What if we really do want 10000+ CPUs?
> >   - And what will that LED array look like to support them all?
> 
> abcc131292aa ("ledtrig-cpu: Limit to 8 CPUs") actually added a
> runtime limit to eight CPUS, which is probably more reasonable.
> 
> > - If we're enforcing here, is the BUILD_BUG_ON() now superfluous?
> 
> Yes, but it documents the requirement better than just the
> Kconfig dependency. Since there is a runtime limit, we could
> probably just drop the compile-time check and not add the
> Kconfig check.

Your call.  I trust your judgement.

All of this was just a thought experiment.

-- 
Lee Jones [李琼斯]