Hello, On Mon, May 27, 2024 at 01:51:49PM +0100, Russell King (Oracle) wrote: > On Mon, May 27, 2024 at 02:28:59PM +0200, Uwe Kleine-König wrote: > > On Mon, May 27, 2024 at 08:56:16AM +0100, Russell King (Oracle) wrote: > > > On Mon, May 27, 2024 at 09:43:41AM +0200, Thorsten Scherer wrote: > > > > Hello, > > > > > > > > in the context of a panic on an i.MX25 based v6.9 kernel [1] Uwe > > > > pointed me to > > > > this thread. With the proposed code change applied the procedure > > > > > > > > # set to some known good (randomly guessed) filter function and > > > > enable function_graph > > > > echo mtdblock_open > set_ftrace_filter > > > > echo function_graph > current_tracer > > > > > > > > # walk available filter funcs > > > > cat available_filter_functions | while read f; do echo $f | tee -a > > > > set_ftrace_filter; sleep 1; done > > > > > > > > produces the following output > > > > > > > > [ 159.832173] Insufficient stack space to handle exception! > > > > [ 159.832241] Task stack: [0xc8e44000..0xc8e46000] > > > > [ 159.842701] IRQ stack: [0xc8800000..0xc8802000] > > > > [ 159.847712] Overflow stack: [0xc1934000..0xc1935000] > > > > [ 159.852726] Internal error: Oops - BUG: 0 [#1] PREEMPT ARM > > > > [ 159.858273] Modules linked in: capture_events_imxgpt ti_ads7950 > > > > industrialio_triggered_buffer kfifo_buf capture_events_irq > > > > capture_events iio_trig_hrtimer industrialio_sw_trigger > > > > industrialio_configfs dm_mod > > > > [ 159.876948] CPU: 0 PID: 199 Comm: sh Not tainted 6.9.0 #3 > > > > [ 159.882412] Hardware name: Freescale i.MX25 (Device Tree Support) > > > > [ 159.888547] PC is at prepare_ftrace_return+0x4/0x7c > > > > [ 159.893520] LR is at ftrace_graph_caller+0x1c/0x28 > > > > [ 159.898376] pc : [<c010dd44>] lr : [<c010d988>] psr: 60000093 > > > > [ 159.904690] sp : c8e44018 ip : c8e44018 fp : c8e4403c > > > > [ 159.909959] r10: c0c09e78 r9 : c35e9bc0 r8 : c010d9bc > > > > [ 159.915227] r7 : 00000001 r6 : 00000004 r5 : c8e44064 r4 : > > > > c8e440ac > > > > [ 159.921800] r3 : c8e44030 r2 : c8e4403c r1 : c010eb9c r0 : > > > > c8e44038 > > > > [ 159.928376] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM > > > > Segment none > > > > [ 159.935652] Control: 0005317f Table: 83074000 DAC: 00000051 > > > > [ 159.941436] Register r0 information: 2-page vmalloc region starting > > > > at 0xc8e44000 allocated at kernel_clone+0xa8/0x408 > > > > [ 159.952253] Register r1 information: non-slab/vmalloc memory > > > > [ 159.957988] Register r2 information: 2-page vmalloc region starting > > > > at 0xc8e44000 allocated at kernel_clone+0xa8/0x408 > > > > [ 159.968791] Register r3 information: 2-page vmalloc region starting > > > > at 0xc8e44000 allocated at kernel_clone+0xa8/0x408 > > > > [ 159.979592] Register r4 information: 2-page vmalloc region starting > > > > at 0xc8e44000 allocated at kernel_clone+0xa8/0x408 > > > > [ 159.990391] Register r5 information: 2-page vmalloc region starting > > > > at 0xc8e44000 allocated at kernel_clone+0xa8/0x408 > > > > [ 160.001187] Register r6 information: non-paged memory > > > > [ 160.006303] Register r7 information: non-paged memory > > > > [ 160.011415] Register r8 information: non-slab/vmalloc memory > > > > [ 160.017139] Register r9 information: slab kmalloc-32 start c35e9bc0 > > > > pointer offset 0 size 32 > > > > [ 160.025718] Register r10 information: non-slab/vmalloc memory > > > > [ 160.031530] Register r11 information: 2-page vmalloc region starting > > > > at 0xc8e44000 allocated at kernel_clone+0xa8/0x408 > > > > [ 160.042422] Register r12 information: 2-page vmalloc region starting > > > > at 0xc8e44000 allocated at kernel_clone+0xa8/0x408 > > > > [ 160.053315] Process sh (pid: 199, stack limit = 0x68fc3abb) > > > > [ 160.058955] Stack: (0xc8e44018 to 0xc8e46000) > > > > > > No backtrace? No Code: line? I'm guessing there was an attempt to ftrace > > > a function involving the ftrace tracing infrastructure, which is why 8KB > > > of stack has been gobbled up. It could be > > > copy_from_kernel_nofault_allowed() but it would be useful to have at > > > least some extract of the backtrace showing the recursive cycle to > > > confirm, otherwise there is nothing in your report to confirm. As I'm > > > not a ftrace user myself, this isn't something I'd test for, so having > > > a full report would be useful. > > > > Is not having a backtrace related to ftrace_return_address() returning > > NULL, as Arnd pointed out in > > https://lore.kernel.org/linux-arm-kernel/36cd10de-c51c-40ff-90e8-714954060...@app.fastmail.com/ > > ? > > Unlikely - the stack and code lines are also missing. I think the > submitter truncated the oops which is highly likely given that it > would've dumped all 8kB of the stack in hex, and the trace and > code lines would be after that.
sorry for causing additional friction by my imprecise description. Indeed, this was the whole oops before the machine restarted. I double checked that. I see that this [1] thread contains a patch. Will test it on my machine. > -- > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ > FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last! Best regards Thorsten [1] https://lore.kernel.org/all/20240527161236.313448-2-ardb+...@google.com/