Re: [PATCH] arm64: irqflags: Fix Pseudo-NMI state assertion failure during vpanic

[Jinjie Ruan <ruanjinjie@huawei.com>]

On 7/13/2026 8:22 PM, Mark Rutland wrote:
> Jinjie,
> 
> Given this will obviously conflict with the NMI rework, and given that
> you know that Vladimir and I are working in this area, you should CC us
> on changes in this area so as to not fragment work.

Hi Mark,

Sorry, I directly used scripts/get_maintainer.pl.

+Cc Vladimir, Liao, Chang

> 
> On Mon, Jul 13, 2026 at 07:44:59PM +0800, Jinjie Ruan wrote:
>> When CONFIG_ARM64_DEBUG_PRIORITY_MASKING is enabled, triggering an LKDTM
>> HARDLOCKUP induces a warning at __pmr_local_irq_disable() inside
>> vpanic().
> 
> Clearly this has never been tested before. What drove you to test this
> specifically?

As you mentioned above, prepare to do some basic test to test the
baseline, pseudo NMI, and the patch that Vladimir supports for FEAT_NMI.

> 
>> This occurs because a Pseudo-NMI interrupts the locked-up CPU and updates
>> ICC_PMR_EL1 to a transient composite state:
>> 	GIC_PRIO_IRQON | GICV3_PRIO_PSR_I_SET (0xf0).
>>
>> Then, vpanic() unconditionally calls local_irq_disable(), triggering
>> the strict assertion which only expects pure IRQON or IRQOFF.
> 
> Is there any non-panic code which could run in this context and call
> local_irq_disable()?

Not available for now.

> 
> If not, I suspect it would be best to leave this as-is, and let it be
> fixed by that rework. There are tonnes of other secondary warnings that
> can be triggered by LKDTM tests, and I don't think this is very
> important.
> 
>> Fix this by expanding the debugging whitelist in __pmr_local_irq_disable()
>> to explicitly permit this valid Pseudo-NMI context flag where DAIF.IF is
>> set to prevent NMI nesting.
> 
> Hmm... that'll silently miss cases where we're in this state and call:
> 
> 	local_irq_disable();
> 	...
> 	local_irq_enable()

Yes, otherwise the assumption that pseudo NMI interrupts by setting the
IRQOFF and IRQON pair to disable irq or enable irq would not hold.

> 
> ... where local_irq_enable() *cannot* work correctly, and will restore
> the wrong state.
> 
> If we have anything of that shape, then we need more significant changes
> here.

Yes, we should drop this fix and leverage this reconstruction supporting
FEAT_NMI to address these corner cases.

I will continue to help test and review Vladimir's patch.

> 
> Mark.
> 
>>
>> 	# echo HARDLOCKUP > /sys/kernel/debug/provoke-crash/DIRECT
>> 	lkdtm: Performing direct entry HARDLOCKUP
>> 	watchdog: CPU3: Watchdog detected hard LOCKUP on cpu 3
>> 	...
>>
>> 	CPU: 3 UID: 0 PID: 219 Comm: sh Not tainted 7.2.0-rc1 #341 PREEMPT
>> 	Hardware name: linux,dummy-virt (DT)
>> 	pstate: 00002005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
>> 	pc : lkdtm_HARDLOCKUP+0x64/0x78
>> 	lr : lkdtm_HARDLOCKUP+0x64/0x78
>> 	sp : ffffffc080b33ac0
>> 	pmr: 000000c0
>> 	x29: ffffffc080b33ac0 x28: ffffff80c3d61ac0 x27: 0000000000000000
>> 	x26: 0000000000000000 x25: ffffff80c0f24800 x24: ffffff80c05495f0
>> 	x23: ffffffc080b33c30 x22: ffffffc080b33c30 x21: ffffffed82f60bb0
>> 	x20: 000000000000000b x19: ffffff80c339d000 x18: 0000000000000001
>> 	x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000028
>> 	x14: 0000000000000000 x13: 0000000000008000 x12: 0000000000000161
>> 	x11: ffffffed837fb000 x10: 0000000000000000 x9 : 0000000000000001
>> 	x8 : ffffffc080b339c8 x7 : ffffffc080b33ab0 x6 : ffffffc080b33a40
>> 	x5 : ffffffc080b33a28 x4 : ffffffc080b34000 x3 : 0000000000000000
>> 	x2 : 0000000100000000 x1 : 0000000100000000 x0 : 0000000000000001
>> 	Call trace:
>> 	 lkdtm_HARDLOCKUP+0x64/0x78 (P)
>> 	 lkdtm_do_action+0x1c/0x38
>> 	 direct_entry+0xd0/0x164
>> 	 full_proxy_write+0x6c/0xa8
>> 	 vfs_write+0xd0/0x354
>> 	 ksys_write+0x68/0xfc
>> 	 __arm64_sys_write+0x1c/0x28
>> 	 invoke_syscall+0x9c/0x10c
>> 	 el0_svc_common.constprop.0+0x40/0xe8
>> 	 do_el0_svc+0x20/0x2c
>> 	 el0_svc+0x5c/0x44c
>> 	 el0t_64_sync_handler+0xa0/0xe4
>> 	 el0t_64_sync+0x1ac/0x1b0
>> 	Sending NMI from CPU 3 to CPUs 0-2,4-7:
>> 	...
>> 	------------[ cut here ]------------
>> 	WARNING: arch/arm64/include/asm/irqflags.h:63 at vpanic+0x3a8/0x574, CPU#3: sh/219
>> 	Modules linked in:
>> 	CPU: 3 UID: 0 PID: 219 Comm: sh Not tainted 7.2.0-rc1 #341 PREEMPT
>> 	Hardware name: linux,dummy-virt (DT)
>> 	pstate: 200020c5 (nzCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
>> 	pc : vpanic+0x3a8/0x574
>> 	lr : do_panic_on_target_cpu+0x0/0x1c
>> 	sp : ffffffc08001bb10
>> 	pmr: 000000f0
>> 	x29: ffffffc08001bb10 x28: 00000000000000f0 x27: 0000000000000003
>> 	x26: 0000000000000000 x25: ffffffed82b902f0 x24: ffffffed81cbba08
>> 	x23: ffffffed830e2000 x22: ffffffed830e21a0 x21: ffffffc08001bbc0
>> 	x20: ffffffed82b94078 x19: ffffffed8225fff8 x18: 00000000ffffffff
>> 	x17: 666f735f6f645f5f x16: 205d3e3832353031 x15: ffffffed83b5bf3b
>> 	x14: 0000000000000001 x13: ffffffed82bba668 x12: 0000000000000188
>> 	x11: 0000000000000498 x10: ffffffed82c2a650 x9 : 0000000100110001
>> 	x8 : ffffff80c3d61ac0 x7 : 0000000000000001 x6 : ffffffed81cbaca8
>> 	x5 : ffffffc080b33980 x4 : ffffffc08001bc50 x3 : 0000000000000001
>> 	x2 : ffffffed82b8f000 x1 : 00000000000000d0 x0 : 0000000000000001
>> 	Call trace:
>> 	 vpanic+0x3a8/0x574 (P)
>> 	 do_panic_on_target_cpu+0x0/0x1c
>> 	 add_taint+0x0/0xbc
>> 	 watchdog_hardlockup_check+0x32c/0x3f8
>> 	 watchdog_overflow_callback+0x34/0x44
>> 	 __perf_event_overflow+0xfc/0x4ec
>> 	 perf_event_overflow+0x30/0xf4
>> 	 armv8pmu_handle_irq+0x114/0x1fc
>> 	 armpmu_dispatch_irq+0x2c/0x68
>> 	 handle_percpu_devid_irq+0xd4/0x268
>> 	 handle_irq_desc+0x40/0x58
>> 	 generic_handle_domain_nmi+0x28/0x50
>> 	 __gic_handle_nmi.constprop.0+0x4c/0xa0
>> 	 gic_handle_irq+0x38/0x2bc
>> 	 call_on_irq_stack+0x30/0x48
>> 	 do_interrupt_handler+0x80/0x94
>> 	 el1_interrupt+0x90/0xac
>> 	 el1h_64_irq_handler+0x18/0x24
>> 	 el1h_64_irq+0x80/0x84
>> 	 lkdtm_HARDLOCKUP+0x64/0x78 (P)
>> 	 lkdtm_do_action+0x1c/0x38
>> 	 direct_entry+0xd0/0x164
>> 	 full_proxy_write+0x6c/0xa8
>> 	 vfs_write+0xd0/0x354
>> 	 ksys_write+0x68/0xfc
>> 	 __arm64_sys_write+0x1c/0x28
>> 	 invoke_syscall+0x9c/0x10c
>> 	 el0_svc_common.constprop.0+0x40/0xe8
>> 	 do_el0_svc+0x20/0x2c
>> 	 el0_svc+0x5c/0x44c
>> 	 el0t_64_sync_handler+0xa0/0xe4
>> 	 el0t_64_sync+0x1ac/0x1b0
>>
>> Cc: catalin.marinas@arm.com
>> Cc: will@kernel.org
>> Cc: stable@vger.kernel.org
>> Fixes: 48ce8f80f5901 ("arm64: irqflags: Introduce explicit debugging for IRQ priorities")
>> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
>> ---
>>  arch/arm64/include/asm/irqflags.h | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/include/asm/irqflags.h b/arch/arm64/include/asm/irqflags.h
>> index a8cb5a5c93b7..c5e3e9fe19a4 100644
>> --- a/arch/arm64/include/asm/irqflags.h
>> +++ b/arch/arm64/include/asm/irqflags.h
>> @@ -60,7 +60,8 @@ static __always_inline void __pmr_local_irq_disable(void)
>>  {
>>  	if (IS_ENABLED(CONFIG_ARM64_DEBUG_PRIORITY_MASKING)) {
>>  		u32 pmr = read_sysreg_s(SYS_ICC_PMR_EL1);
>> -		WARN_ON_ONCE(pmr != GIC_PRIO_IRQON && pmr != GIC_PRIO_IRQOFF);
>> +		WARN_ON_ONCE(pmr != GIC_PRIO_IRQON && pmr != GIC_PRIO_IRQOFF &&
>> +			     pmr != (GIC_PRIO_IRQON | GICV3_PRIO_PSR_I_SET));
>>  	}
>>  
>>  	barrier();
>> -- 
>> 2.34.1
>>
>>
>