Hi Arnd, On Thu, 10 Nov 2022 at 03:33, Arnd Bergmann <arnd@xxxxxxxx> 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
