On Fri, Oct 25, 2024 at 11:27 AM Clement LE GOFFIC <clement.legoffic@xxxxxxxxxxx> wrote: > On 10/24/24 23:58, Linus Walleij wrote: > > 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? > I Linus, > > Yes, I've tried to revert this particular commit on top of your last > patches but I have some conflicts inside arch/arm/kernel/unwind.c What happens if you just git checkout b6506981f880^ And build and boot that? It's just running the commit right before the unwinding patch. Yours, Linus Walleij
