* [PATCH] leds: trigger: ledtrig-cpu:: enforce NR_CPUS limit in Kconfig @ 2025-06-20 11:08 Arnd Bergmann 2025-06-25 9:24 ` Lee Jones 0 siblings, 1 reply; 4+ messages in thread From: Arnd Bergmann @ 2025-06-20 11:08 UTC (permalink / raw) To: Lee Jones, Pavel Machek Cc: Arnd Bergmann, Hans de Goede, linux-leds, linux-kernel 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 ^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH] leds: trigger: ledtrig-cpu:: enforce NR_CPUS limit in Kconfig 2025-06-20 11:08 [PATCH] leds: trigger: ledtrig-cpu:: enforce NR_CPUS limit in Kconfig Arnd Bergmann @ 2025-06-25 9:24 ` Lee Jones 2025-06-25 10:24 ` Arnd Bergmann 0 siblings, 1 reply; 4+ messages in thread From: Lee Jones @ 2025-06-25 9:24 UTC (permalink / raw) To: Arnd Bergmann Cc: Pavel Machek, Arnd Bergmann, Hans de Goede, linux-leds, linux-kernel 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 [李琼斯] ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] leds: trigger: ledtrig-cpu:: enforce NR_CPUS limit in Kconfig 2025-06-25 9:24 ` Lee Jones @ 2025-06-25 10:24 ` Arnd Bergmann 2025-06-25 10:36 ` Lee Jones 0 siblings, 1 reply; 4+ messages in thread From: Arnd Bergmann @ 2025-06-25 10:24 UTC (permalink / raw) To: Lee Jones, Arnd Bergmann Cc: Pavel Machek, Hans de Goede, linux-leds, linux-kernel 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] leds: trigger: ledtrig-cpu:: enforce NR_CPUS limit in Kconfig 2025-06-25 10:24 ` Arnd Bergmann @ 2025-06-25 10:36 ` Lee Jones 0 siblings, 0 replies; 4+ messages in thread From: Lee Jones @ 2025-06-25 10:36 UTC (permalink / raw) To: Arnd Bergmann Cc: Arnd Bergmann, Pavel Machek, Hans de Goede, linux-leds, linux-kernel 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 [李琼斯] ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2025-06-25 10:36 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2025-06-20 11:08 [PATCH] leds: trigger: ledtrig-cpu:: enforce NR_CPUS limit in Kconfig Arnd Bergmann 2025-06-25 9:24 ` Lee Jones 2025-06-25 10:24 ` Arnd Bergmann 2025-06-25 10:36 ` Lee Jones
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).