[PATCH v3 1/2] ARM: ioremap: Sync PGDs for VMALLOC shadow

[Linus Walleij]

On Fri, Oct 25, 2024 at 11:27 AM Clement LE GOFFIC
<clement.legoffic at foss.st.com> 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 at foss.st.com> 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