ppc64le fails on RUST_OPT_LEVEL_{0,1} #155
Copy link
Copy link
Closed
Labels
• archRelated to a particular arch, `arch/` support in general...Related to a particular arch, `arch/` support in general...
Description
Large array has length: 514
Kernel panic - not syncing: corrupted stack end detected inside scheduler
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.12.0-rc3+ #1
Removing the large array does not fix it -- something else is going on.
When this is fixed, switch the CI debug config back to RUST_OPT_LEVEL_0.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
• archRelated to a particular arch, `arch/` support in general...Related to a particular arch, `arch/` support in general...
Activity
mpe commentedon Apr 10, 2021
This is caused by stack overflow. We have 16K stacks, but there are functions generated with ~20K frames!
The stack trace for that panic is:
Looking up the stack I see this function:
The disassembly is:
That
stduis creating a20528byte stack frame.Building with
-Z emit-stack-sizesI see ~30 Rust functions that have large (> 2KB) frames.mpe commentedon Apr 10, 2021
I can fix the CI failure at opt level 0 by increasing the stack size, do we want to do that for now?
See mpe/linux@27a1886
ojeda commentedon Apr 10, 2021
It would be nice to do it, yeah. We should also add a comment in
CONFIG_RUST_OPT_LEVEL_0and1explaining that the stack size might need a substantial increase in some cases.Also please update
Doc/rust/arch-support.rstto remove the restriction! :-)mpe commentedon Apr 13, 2021
For the record here are the functions I see with frames > 2KB:
netfilter: nft_set_pipapo: release elements in clone from abort path
drm/drm_exec: Work around a WW mutex lockdep oddity
drm/tests: helpers: Avoid a driver uaf