PPC code-patching calls tlb flush with irqs disabled?

[Christophe Leroy]

Le 19/11/2025 à 08:38, Christian Melki a écrit :
> [Vous ne recevez pas souvent de courriers de christian.melki at westermo.com. 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 ?