Change:
if libc::sched_getaffinity(0, mem::size_of::<libc::cpu_set_t>(), &mut set) == 0 { let count = libc::CPU_COUNT(&set) as usize; let count = count.min(quota); <del> // SAFETY: affinity mask can't be empty and the quota gets clamped to a minimum of 1 return Ok(NonZeroUsize::new_unchecked(count)); </del> <ins> // reported to occur on MIPS kernels older than our minimum supported kernel version for those targets let count = NonZeroUsize::new(count) .expect("CPU count must be > 0. This may be a bug in sched_getaffinity(); try upgrading the kernel."); return Ok(count); </ins> } } }

Discussion:
available_parallelism() return 0 I tried this code: : ! <details<summarycat /proc/cpuinfo</summary<p</p</details
Looking at the , it appears that if returned 0 it would indeed be a problem, but why would that be? Could you try to run this small program, and return us the output of it? If it prints out for the could you also attach . label +T-libs +I-prioritize +O-linux -needs-triage
!
Can you post the output of running your test program with ? I'm just hoping you have some way to get strace onto this router :pray:
Right, that's what I thought. Let's try to pin point where the bug is by trying the same thing in C. Could you try to run this small program, and return us the output of it?
I think for any reason, when the value of 'CPUCOUNT' is 0, 'availableparallelism' should return Err
Sorry, I don't know how to compile C program onto the router
Well yes, but we shouldn't get 0 for starter. Hum, that's a bummer. Then I don't know how to debug this further.
Can you provide the compiled binary for me to run? The system environment has been given
I'm sorry, I don't know your environment, and I haven't used any MIPS. However if you able to compile with  as a dependency, we might be able to continue debugging. Could you try to run this small program, and return us the output of it? <details if needed</summary</details
Related: Unlike numcpus, which returns usize, std returns NoneZeroUsize, so this is a soundness issue. label +I-unsound
should probably just handle this by returning if fails rather than using . It's a weird issue (obviously there is at least 1 CPU if code is running) but who knows.
Maybe it's worth saying this explicitly: As far as I can tell by reading the man pages, this is a bug in glibc or Linux. The man pages for and don't look like there is any wiggle room for a platform to behave like this. Has anyone tried reporting this upstream?

This issue is not the first time this problem has been encountered, but it looks to me like everyone else has papered over it.
If we're down for cursed things, this program will print the raw bytes in the cpuset which would at least let us know if the kernel is putting anything in there:
libc::CPUCOUNT is implemented in pure rust with straightforward code: I'm not sure I think there's a way for that code to fail to miss any bits.
you haven't mentioned which target-triple you're compiling for. Some are tier 2 and some are tier 3. Some use glibc, some musl. This could be relevant if it's a bug in libc.
This kernel version and is below the for the tier 2 mips-gnu targets.
The docs for already mention that it returns an estimate, rather than an accurate count. I take this mean a lower bound, so a fallback of would be consistent with my expectations. But I'll admit the docs do also seem to contradict themselves a few paragraphs later:
Regardless of whether this kernel is EOL (we support plenty of EOL kernels) and whether the wobbliness of applies here (I'm sure it doesn't, and it would be terrible for us to retcon this as permitted behavior), I think the problem here is that your kernel is buggy. A quick Google search for "mips schedgetaffinity" turns up this patch: Just going off vibes, this looks like it fixes the bug we are talking about. As was pointed out correctly above, the kernel you're using is not supported by this target, and upgrading to a supported kernel would bring in the patch above. Can you confirm that upgrading to a supported kernel (at least 4.4)? If an upgrade to at least Linux 4.4 fixes this issue, I do not think we should try to fall back to returning 1 if says . Might be nice to panic instead of executing UB though.
Yeah, panic makes sense. We should notify users that the system is bugged and unsupported. I'll make a PR.