[Toybox] [PATCH] taskset: fix buffer overflow from long mask

Rob Landley rob at landley.net
Thu Jun 26 11:24:10 PDT 2025


On 6/23/25 18:12, David Seikel wrote:
> On 2025-06-23 15:22:05, Rob Landley wrote:
>>> Tested:
>>> % toybox taskset $( yes f | head -n 8193 | tr -d '\n' ) true
>>> taskset: mask too long
>>>
>>> The util-linux taskset handles masks longer than zsh can construct:
>>> taskset $( yes f | head -n 131000 | tr -d '\n' ) true
>>
>> Before using a fixed 4k bitmap (32768 processors) for taskset I went down
>> ANOTHER historical rathole, "how many processors can a Linux system actually
>> have". I'm pretty sure I redid the research and actually wrote it down this
>> time back when commit e2b17f5e0cd3 went in. Checking my blog back around
>> then, we get:
>>
>> https://landley.net/notes-2022.html#24-07-2022
>>
>> Which said only IBM used more than 64 processors in a defconfig (some
>> powerpc set NR_CPUS to 2048 and s390x could set it to 512). That symbol sets
>> the size of the array and thus the maximum this kernel could handle, not the
>> amount actually present on any given hardware instance (usually way fewer
>> than that).
> 
> This probably isn't relevant, but the desktop computer I'm typing this on
> has 64 cores.  Or 128 coz hyperthreading.  It's my super desktop, it has
> way too much RAM as well.

So in 3 and 1/2 years, a system even the person who puts it together 
describes as 'way too much" went from 64 to 64 plus hyperthreading.

$ cd ~/linux/linux
$ git describe --tags
v6.15-8297-ge0797d3b91de
$ grep -rA6 'config NR_CPUS' arch | grep range
arch/xtensa/Kconfig-	range 2 32
arch/powerpc/platforms/Kconfig.cputype-	range 2 8192 if SMP
arch/alpha/Kconfig-	range 2 32
arch/sparc/Kconfig-	range 2 32 if SPARC32
arch/sparc/Kconfig-	range 2 4096 if SPARC64
arch/riscv/Kconfig-	range 2 512 if !RISCV_SBI_V01
arch/riscv/Kconfig-	range 2 32 if RISCV_SBI_V01 && 32BIT
arch/riscv/Kconfig-	range 2 64 if RISCV_SBI_V01 && 64BIT
arch/s390/Kconfig-	range 2 512
arch/mips/Kconfig-	range 2 256
arch/openrisc/Kconfig-	range 2 32
arch/hexagon/Kconfig-	range 2 6 if SMP
arch/arc/Kconfig-	range 2 4096
arch/x86/Kconfig-	range NR_CPUS_RANGE_BEGIN NR_CPUS_RANGE_END
arch/um/Kconfig-	range 1 1
arch/loongarch/Kconfig-	range 2 256
arch/sh/Kconfig-	range 2 32
arch/csky/Kconfig-	range 2 32
arch/arm64/Kconfig-	range 2 4096
arch/parisc/Kconfig-	range 2 32
arch/arm/Kconfig-	range 2 16 if DEBUG_KMAP_LOCAL
arch/arm/Kconfig-	range 2 32 if !DEBUG_KMAP_LOCAL

Yeah, I remain comfortable with my analysis.

Rob

P.S. x86 is 2 to 8192, it's just terrible about expressing it.

P.P.S. Hexagon isn't really SMP at all, it's a 
https://en.wikipedia.org/wiki/Barrel_processor basically doing 6x 
hyperthreading in a way that avoided pipeline stage interlocks and 
memory access stalls. And the generation after the one I worked with did 
4x because Erich Plondke redid the architecture to have fewer pipeline 
stages.

P.P.P.S. No seriously, x86 is terrible: the RANGE_BEGIN and RANGE_END 
nonsense in arch/x86/Kconfig is a damning indictment of that platform's 
maintainers' design sensibilities, but then that is the only one that 
needed 
https://landley.net/bin/mkroot/0.8.11/linux-patches/0008-elfcrap.patch 
which is now 
https://landley.net/bin/mkroot/0.8.12/linux-patches/0005-x86-64-elfcrap.patch 
just to build with the same dependencies as every other architecture. 
Anyway, their limit is still 8192 and when I did that research years ago 
the machines attempting to USE anywhere near that limit had long been 
abandoned as commercially infeasible. The top500 stuff is all clusters 
because of the laws of physics, and they use live migration across nodes 
as a cluster load balancing thing to dynamically minimize latency. 
(People should really put DATES on papers, 
https://www.ssrg.ece.vt.edu/papers/FedICI.pdf cites a paper from 2012 at 
the end so I'm assuming it's more than a decade old, but I shouldn't 
have to stop and scrub for that... Ah, Jerry Springer says it's 2014: 
https://link.springer.com/chapter/10.1007/978-3-642-54420-0_12 . At 
least https://openproceedings.org/2012/conf/edbt/BarkerCMHS12.pdf is in 
a directory called "2012"...)


More information about the Toybox mailing list