Le 19/11/2025 à 08:38, Christian Melki a écrit :
[Vous ne recevez pas souvent de courriers de [email protected]. Découvrez pourquoi ceci est important à https://aka.ms/LearnAboutSenderIdentification ] A little bit of enabled debugging gave this lockdep irq warning. The machine is a e5500 Book-E running in 32-bit (e500mc). ------------[ cut here ]------------ WARNING: CPU: 0 PID: 0 at kernel/smp.c:807 smp_call_function_many_cond+0x520/0x700 Modules linked in: CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.45-5.26+ #1 Hardware name: wmo,Viper-<LEGACYSWCLASS>12A e5500 0x80241021 CoreNet Generic NIP: c016c9c8 LR: c016c510 CTR: c00d2dd4 REGS: c216ddb0 TRAP: 0700 Not tainted (6.12.45-5.26+) MSR: 00021002 <CE,ME> CR: 24004888 XER: 20000000 GPR00: c016cccc c216de90 c20725c0 00000000 c116d440 00000000 00000001 00000000 GPR08: 1c6bb000 00000003 00000003 76153240 84004888 6ccf16ef 1ff29e0c 0ff51000 GPR16: 1fe9a6fc 00000004 00000000 00000000 00000000 00000000 00000000 c21a0000 GPR24: 00000001 c016cccc 00000000 00000000 c0021640 c219b528 00000000 00000001 NIP [c016c9c8] smp_call_function_many_cond+0x520/0x700 LR [c016c510] smp_call_function_many_cond+0x68/0x700 Call Trace: [c216de90] [c00dd268] lock_acquire.part.0+0x124/0x338 (unreliable) [c216def0] [c016cccc] smp_call_function+0x4c/0xa8 [c216df10] [c00218e8] flush_tlb_kernel_range+0x28/0x7c [c216df20] [c0023170] patch_mem.constprop.0+0x13c/0x1ec [c216df50] [c02b71e0] __jump_label_update+0x78/0x130 [c216df80] [c02b82d4] static_key_slow_inc_cpuslocked+0x9c/0xf0 [c216dfa0] [c2013494] sched_clock_init+0x1c/0x64 [c216dfb0] [c200130c] start_kernel+0x40c/0x530 [c216dff0] [c00003e4] set_ivor+0x13c/0x178 Code: 7ea9402e 81220000 3929ffff 2c090000 91220000 40c20014 81220080 71290004 41c20008 48d64931 2c150000 40c201cc <0fe00000> 82810030 4bfffc30 60000000 irq event stamp: 170 hardirqs last enabled at (169): [<c0edc424>] _raw_spin_unlock_irqrestore+0x74/0xb0 hardirqs last disabled at (170): [<c0023204>] patch_mem.constprop.0+0x1d0/0x1ec softirqs last enabled at (10): [<c004a50c>] handle_softirqs+0x400/0x418 softirqs last disabled at (3): [<c0006654>] do_softirq_own_stack+0x34/0x4c ---[ end trace 0000000000000000 ]--- Seems patch_mem() in code-patching.c is doing interesting things here? I don't get why it disables irqs and calls TLB flushing. How does that work with SMP IPIs? Maybe this warning is a dud for 32-bit Book-Es nohash MMU?
We don't want an interrupt in the middle of a patching sequence were the code would be in a wobbly situation. We also don't want other parts of kelnel being able to access that temporary RW mapping of kernel code until it is unmapped.
How can we achieve this goal if we can't flush TLBs while IRQs are disabled ?
