[PATCH v3 1/2] ARM: ioremap: Sync PGDs for VMALLOC shadow
Clement LE GOFFIC
clement.legoffic at foss.st.com
Fri Oct 25 02:24:33 PDT 2024
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
More information about the linux-arm-kernel
mailing list