Hi Arnd,
On Thu, 10 Nov 2022 at 03:33, Arnd Bergmann arnd@arndb.de wrote:
On Wed, Nov 9, 2022, at 13:57, Arnd Bergmann wrote:
One thing that sticks out is the print_constraints_debug() function in the regulator framework, which uses a larger-than-average stack to hold a string buffer, and then calls into the low-level driver to get the actual data (regulator_get_voltage_rdev, _regulator_is_enabled). Splitting the device access out into a different function from the string handling might reduce the stack usage enough to stay just under the 8KB limit, though it's probably not a complete fix. I added the regulator maintainers to Cc for thoughts on this.
I checked the stack usage for each of the 147 functions in the backtrace, and as I was guessing print_constraints_debug() is the largest, but it's still only 168 bytes, and everything else is smaller, so no point hacking this.
168 print_constraints_debug 96 timekeeping_advance 64 set_machine_constraints 64 of_i2c_register_device 56 of_platform_bus_create 48 schedule_timeout
One more idea I had is the unwinder: since this kernel is built with the frame-pointer unwinder, I think the stack usage per function is going to be slightly larger than with the arm unwinder.
Naresh, how hard is it to reproduce this bug intentionally? Can you try if it still happens if you change the .config to use these:?
# CONFIG_FUNCTION_GRAPH_TRACER is not set # CONFIG_UNWINDER_FRAME_POINTER is not set CONFIG_UNWINDER_ARM=y
I have done this experiment and reported crash not reproduced after eight rounds of testing [1].
https://lkft.validation.linaro.org/scheduler/job/5835922#L1993
Arnd
- Naresh