Hi Clement, I saw I missed to look closer at the new bug found in ext4 on the STM32: On Mon, Oct 21, 2024 at 2:12 PM Clement LE GOFFIC <clement.legoffic@xxxxxxxxxxx> wrote: > Perhaps not related with this topic but as in the backtrace I am getting > some keyword from our start exchange, I dump the crash below. > If this backtrace is somehow related with our issue, please have a look. (...) > [ 1439.351945] PC is at __read_once_word_nocheck+0x0/0x8 > [ 1439.356965] LR is at unwind_exec_insn+0x364/0x658 (...) > [ 1440.333183] __read_once_word_nocheck from unwind_exec_insn+0x364/0x658 > [ 1440.339726] unwind_exec_insn from unwind_frame+0x270/0x618 > [ 1440.345352] unwind_frame from arch_stack_walk+0x6c/0xe0 > [ 1440.350674] arch_stack_walk from stack_trace_save+0x90/0xc0 > [ 1440.356308] stack_trace_save from kasan_save_stack+0x30/0x4c > [ 1440.362042] kasan_save_stack from __kasan_record_aux_stack+0x84/0x8c > [ 1440.368473] __kasan_record_aux_stack from task_work_add+0x90/0x210 > [ 1440.374706] task_work_add from scheduler_tick+0x18c/0x250 > [ 1440.380245] scheduler_tick from update_process_times+0x124/0x148 > [ 1440.386287] update_process_times from tick_sched_handle+0x64/0x88 > [ 1440.392521] tick_sched_handle from tick_sched_timer+0x60/0xcc > [ 1440.398341] tick_sched_timer from __hrtimer_run_queues+0x2c4/0x59c > [ 1440.404572] __hrtimer_run_queues from hrtimer_interrupt+0x1bc/0x3a0 > [ 1440.411009] hrtimer_interrupt from arch_timer_handler_virt+0x34/0x3c > [ 1440.417447] arch_timer_handler_virt from > handle_percpu_devid_irq+0xf4/0x368 > [ 1440.424480] handle_percpu_devid_irq from > generic_handle_domain_irq+0x38/0x48 > [ 1440.431618] generic_handle_domain_irq from gic_handle_irq+0x90/0xa8 > [ 1440.437953] gic_handle_irq from generic_handle_arch_irq+0x30/0x40 > [ 1440.444094] generic_handle_arch_irq from __irq_svc+0x88/0xc8 > [ 1440.449920] Exception stack(0xde803a30 to 0xde803a78) > [ 1440.454914] 3a20: de803b00 > 00000000 00000001 000000c0 > [ 1440.463141] 3a40: e5333f40 de803ba0 de803bd0 00000001 e5333f40 > de803b00 c1241d90 bad0075c > [ 1440.471262] 3a60: c20584b8 de803a7c c0114114 c0113850 200f0013 ffffffff > [ 1440.477959] __irq_svc from unwind_exec_insn+0x4/0x658 > [ 1440.483078] unwind_exec_insn from call_with_stack+0x18/0x20 This is hard to analyze without being able to reproduce it, but it talks about the stack and Kasan and unwinding, so could it (also) be related to the VMAP:ed stack? Did you try to revert (or check out the commit before and after) b6506981f880 ARM: unwind: support unwinding across multiple stacks to see if this is again fixing the issue? Yours, Linus Walleij
