user0/rust
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
rust/library
History
Matthias Krüger 2dd2fb728e
Rollup merge of #104493 - adamncasey:cgroupzeroperiod, r=m-ou-se 
available_parallelism: Gracefully handle zero value cfs_period_us

There seem to be some scenarios where the cgroup cpu quota field `cpu.cfs_period_us` can contain `0`. This field is used to determine the "amount" of parallelism suggested by the function `std:🧵:available_parallelism`

A zero value of this field cause a panic when `available_parallelism()` is invoked. This issue was detected by the call from binaries built by `cargo test`. I really don't feel like `0` is a good value for `cpu.cfs_period_us`, but I also don't think applications should panic if this value is seen.

This panic started happening with rust 1.64.0.

This case is gracefully handled by other projects which read this information: [num_cpus](e437b9d908/src/linux.rs (L207-L210)), [ninja](https://github.com/ninja-build/ninja/pull/2174/files), [dotnet](c4341d45ac/src/coreclr/pal/src/misc/cgroup.cpp (L481-L483))

Before this change, running `cargo test` in environments configured as described above would trigger this panic:
```
$ RUST_BACKTRACE=1 cargo test
    Finished test [unoptimized + debuginfo] target(s) in 3.55s
     Running unittests src/main.rs (target/debug/deps/x-9a42e145aca2934d)
thread 'main' panicked at 'attempt to divide by zero', library/std/src/sys/unix/thread.rs:546:70
stack backtrace:
   0: rust_begin_unwind
   1: core::panicking::panic_fmt
   2: core::panicking::panic
   3: std::sys::unix:🧵:cgroups::quota
   4: std::sys::unix:🧵:available_parallelism
   5: std:🧵:available_parallelism
   6: test::helpers::concurrency::get_concurrency
   7: test::console::run_tests_console
   8: test::test_main
   9: test::test_main_static
  10: x::main
             at ./src/main.rs:1:1
  11: core::ops::function::FnOnce::call_once
             at /tmp/rust-1.64-1.64.0-1/library/core/src/ops/function.rs:248:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
error: test failed, to rerun pass '--bin x'
```

I've tested this change in an environment which has the bad (questionable?) setup and rebuilding the test executable against a fixed std library fixes the panic.
2022-12-28 22:22:18 +01:00
..
alloc Rollup merge of #105484 - nbdd0121:upcast, r=compiler-errors 2022-12-28 15:51:41 +08:00
backtrace@07872f28cd Update backtrace 2022-09-02 16:09:58 -04:00
core Rollup merge of #106172 - estebank:suggest-impl-trait, r=compiler-errors 2022-12-28 14:40:00 +01:00
panic_abort Remove std's transitive dependency on cfg-if 0.1 2022-11-02 18:01:20 -04:00
panic_unwind Rollup merge of #103989 - arlosi:arm32-panic, r=Amanieu 2022-11-19 15:35:20 +01:00
portable-simd Fix rustdoc lints 2022-11-06 17:21:22 -05:00
proc_macro Add a "the" to proc_macro documentation 2022-12-12 16:19:18 +01:00
profiler_builtins Fully stabilize NLL 2022-06-03 17:16:41 -04:00
rtstartup Remove custom frame info registration on i686-pc-windows-gnu 2022-08-23 16:12:58 +08:00
rustc-std-workspace-alloc Switch all libraries to the 2021 edition 2021-12-23 19:03:47 +08:00
rustc-std-workspace-core Switch all libraries to the 2021 edition 2021-12-23 19:03:47 +08:00
rustc-std-workspace-std Switch all libraries to the 2021 edition 2021-12-23 19:03:47 +08:00
std Rollup merge of #104493 - adamncasey:cgroupzeroperiod, r=m-ou-se 2022-12-28 22:22:18 +01:00
stdarch@790411f93c library: update stdarch submodule 2022-10-13 09:41:16 +08:00
test Fix uninlined_format_args in libtest 2022-12-19 08:58:40 +01:00
unwind Rollup merge of #104464 - mati865:reduce-eh-overallocation-amd64, r=thomcc 2022-11-22 16:36:37 +05:30