* [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).