From nobody Sat Jun 13 13:34:47 2026 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id A7E5B311959 for ; Thu, 7 May 2026 11:05:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778151930; cv=none; b=KF4aN6JkpMFrpu3Rn+AwfTCOJZaeYz5+hIci4uOlgw+a/FqfiMUY02OZuYc8IURYfKoDqdzEND/j4fQ0r5tCoCk/pzwMmvEL+6Xm4Ku64l6NKJgJLVup9oSbVQJLxEFaxSeYY0dKoyttD77DcLy+Y+dW7uWsOeLYq/7+viaOVkU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778151930; c=relaxed/simple; bh=wki4NPv8KFKlfTl742dl39rFSZr4zg2I8w7bdQu54mo=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version:Content-Type; b=twnVFCVMnq4RrKmmHi4TQgR9uNupwyTuMtGw2y1GrkW2TxSlrmBcWoAy+vvrP8I3qAHor79RrmuEGFxRclLGSs1bzv3roVCui7EFg0yYc6NgW8t3T75xJ9j95/rkCrkCc9EB9Lio/vSrotZnE+PQayM8IsxqPNpxwjzscezN9NI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=DFVhaRBR; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="DFVhaRBR" Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 8FBDA2641; Thu, 7 May 2026 04:05:21 -0700 (PDT) Received: from lakrids.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 2BC843F763; Thu, 7 May 2026 04:05:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1778151926; bh=wki4NPv8KFKlfTl742dl39rFSZr4zg2I8w7bdQu54mo=; h=From:To:Cc:Subject:Date:From; b=DFVhaRBRiYa06qLYPI7YYaM0h2x7JVqVt0xklWI5JKPqBmtk2PzG2sN1dP0FbBMVo 0+encniQr4PlaUKkPTlOFC9y6t7Vsq7cBIf96YY4A8gwd3MTDJS60+ZWD3kScCFEmQ ikioX+VP13afbaX8uk9GqYjUXdiKtvudHOje1HqA= From: Mark Rutland To: linux-kernel@vger.kernel.org, Thomas Gleixner Cc: ada.coupriediaz@arm.com, justin.he@arm.com, mark.rutland@arm.com, maz@kernel.org, mhklinux@outlook.com, vladimir.murzin@arm.com Subject: [PATCH] genirq/chip: Don't call add_interrupt_randomness() for NMIs Date: Thu, 7 May 2026 12:05:18 +0100 Message-Id: <20260507110518.3128248-1-mark.rutland@arm.com> X-Mailer: git-send-email 2.30.2 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Recently handle_percpu_devid_irq() was changed to call add_interrupt_randomness(). This introduced a potential deadlock when handle_percpu_devid_irq() is used to handle an NMI, which can be detected with lockdep, e.g. =C2=A0 =C2=A0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =C2=A0 =C2=A0 WARNING: inconsistent lock state =C2=A0 =C2=A0 7.1.0-rc2-pnmi #465 Not tainted =C2=A0 =C2=A0 -------------------------------- =C2=A0 =C2=A0 inconsistent {INITIAL USE} -> {IN-NMI} usage. =C2=A0 =C2=A0 perf/695 [HC1[1]:SC0[0]:HE0:SE1] takes: =C2=A0 =C2=A0 ffff00837dfd3a18 (&base->lock){-.-.}-{2:2}, at: lock_timer_ba= se+0x6c/0xac =C2=A0 =C2=A0 {INITIAL USE} state was registered at: =C2=A0 =C2=A0 =C2=A0 lock_acquire+0x260/0x40c =C2=A0 =C2=A0 =C2=A0 _raw_spin_lock_irqsave+0x68/0xb0 =C2=A0 =C2=A0 =C2=A0 lock_timer_base+0x6c/0xac =C2=A0 =C2=A0 =C2=A0 __mod_timer+0x100/0x32c =C2=A0 =C2=A0 =C2=A0 add_timer_global+0x2c/0x40 =C2=A0 =C2=A0 =C2=A0 __queue_delayed_work+0xf0/0x140 =C2=A0 =C2=A0 =C2=A0 queue_delayed_work_on+0x134/0x138 =C2=A0 =C2=A0 =C2=A0 mem_cgroup_css_online+0x30c/0x310 =C2=A0 =C2=A0 =C2=A0 online_css+0x34/0x10c =C2=A0 =C2=A0 =C2=A0 cgroup_init_subsys+0x158/0x1c8 =C2=A0 =C2=A0 =C2=A0 cgroup_init+0x440/0x524 =C2=A0 =C2=A0 =C2=A0 start_kernel+0x888/0x998 =C2=A0 =C2=A0 =C2=A0 __primary_switched+0x88/0x90 =C2=A0 =C2=A0 irq event stamp: 62068 =C2=A0 =C2=A0 hardirqs last=C2=A0 enabled at (62067): [] = seqcount_lockdep_reader_access.constprop.0+0xf0/0xfc =C2=A0 =C2=A0 hardirqs last disabled at (62068): [] _raw_= spin_lock_irqsave+0x94/0xb0 =C2=A0 =C2=A0 softirqs last=C2=A0 enabled at (62050): [] = put_cpu_fpsimd_context+0x1c/0x4c =C2=A0 =C2=A0 softirqs last disabled at (62048): [] get_c= pu_fpsimd_context+0x1c/0x4c =C2=A0 =C2=A0 =C2=A0 =C2=A0 other info that might help us debug this: =C2=A0 =C2=A0 Possible unsafe locking scenario: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0CPU0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0---- =C2=A0 =C2=A0 =C2=A0 lock(&base->lock); =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 lock(&base->lock); =C2=A0 =C2=A0 =C2=A0 =C2=A0 *** DEADLOCK *** =C2=A0 =C2=A0 3 locks held by perf/695: =C2=A0 =C2=A0 =C2=A0#0: ffff0080146cd2c8 (&type->i_mutex_dir_key#6){++++}-{= 4:4}, at: lookup_slow+0x30/0x68 =C2=A0 =C2=A0 =C2=A0#1: ffff80008332b858 (rcu_read_lock){....}-{1:3}, at: b= lk_mq_run_hw_queue+0xf4/0x1fc =C2=A0 =C2=A0 =C2=A0#2: ffff008000b6aa18 (&host->lock){-.-.}-{3:3}, at: ata= _scsi_queuecmd+0x28/0x88 =C2=A0 =C2=A0 stack backtrace: =C2=A0 =C2=A0 CPU: 3 UID: 0 PID: 695 Comm: perf Not tainted 7.1.0-rc2-pnmi = #465 PREEMPT =C2=A0 =C2=A0 Hardware name: ARM LTD Morello System Development Platform, B= IOS EDK II Mar=C2=A0 7 2024 =C2=A0 =C2=A0 Call trace: =C2=A0 =C2=A0 =C2=A0show_stack+0x18/0x24 (C) =C2=A0 =C2=A0 =C2=A0dump_stack_lvl+0xc4/0x148 =C2=A0 =C2=A0 =C2=A0dump_stack+0x18/0x24 =C2=A0 =C2=A0 =C2=A0print_usage_bug.part.0+0x29c/0x364 =C2=A0 =C2=A0 =C2=A0lock_acquire+0x364/0x40c =C2=A0 =C2=A0 =C2=A0_raw_spin_lock_irqsave+0x68/0xb0 =C2=A0 =C2=A0 =C2=A0lock_timer_base+0x6c/0xac =C2=A0 =C2=A0 =C2=A0add_timer_on+0x78/0x16c =C2=A0 =C2=A0 =C2=A0add_interrupt_randomness+0x124/0x134 =C2=A0 =C2=A0 =C2=A0handle_percpu_devid_irq+0xd4/0x16c =C2=A0 =C2=A0 =C2=A0handle_irq_desc+0x40/0x58 =C2=A0 =C2=A0 =C2=A0generic_handle_domain_nmi+0x28/0x50 =C2=A0 =C2=A0 =C2=A0__gic_handle_nmi.isra.0+0x4c/0xa0 =C2=A0 =C2=A0 =C2=A0gic_handle_irq+0x38/0x2bc =C2=A0 =C2=A0 =C2=A0call_on_irq_stack+0x30/0x48 =C2=A0 =C2=A0 =C2=A0do_interrupt_handler+0x80/0x98 =C2=A0 =C2=A0 =C2=A0el1_interrupt+0x90/0xac =C2=A0 =C2=A0 =C2=A0el1h_64_irq_handler+0x18/0x24 =C2=A0 =C2=A0 =C2=A0el1h_64_irq+0x80/0x84 [...] During review, Thomas pointed out it wouldn't be safe for handle_percpu_devid_irq() to call add_interrupt_randomness() if it was used to handle NMIs: https://lore.kernel.org/lkml/87bjgik042.ffs@tglx/ ... but evidently people missed that handle_percpu_devid_irq() *is* used for NMIs. While it might seem that we should handle NMIs with a separate handle_percpu_devid_nmi() function, for various structural reasons this was impractical, and handle_percpu_devid_irq() has been expected to be used for NMIs since commits: 21bbbc50f398f ("irqchip/gic-v3: Switch high priority PPIs over to handle_= percpu_devid_irq()") 5ff78c8de9d83 ("genirq: Kill handle_percpu_devid_fasteoi_nmi()") Taking the above into account, avoid the deadlock by not calling add_interrupt_randomness() when handle_percpu_devid_irq() is called in an NMI context. This is consistent with our other NNI handling flows, which do not call add_interrupt_randomness(). At the same time, update the kerneldoc comment to make it clear that handle_percpu_devid_irq() can be called in NMI context. The rest of handle_percpu_devid_irq() is currently NMI safe and doesn't need to change. Fixes: fd7400cfcbaa ("genirq/chip: Invoke add_interrupt_randomness() in han= dle_percpu_devid_irq()") Reported-by: Ada Couprie Diaz Signed-off-by: Mark Rutland Cc: Justin He Cc: Marc Zyngier Cc: Michael Kelley Cc: Thomas Gleixner Cc: Vladimir Murzin Reviewed-by: Jinjie Ruan Reviewed-by: Marc Zyngier --- kernel/irq/chip.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c index 6c9b1dc4e7d46..b635e3c5d5b6b 100644 --- a/kernel/irq/chip.c +++ b/kernel/irq/chip.c @@ -14,6 +14,7 @@ #include #include #include +#include #include =20 #include @@ -893,7 +894,10 @@ void handle_percpu_irq(struct irq_desc *desc) * * action->percpu_dev_id is a pointer to percpu variables which * contain the real device id for the cpu on which this handler is - * called + * called. + * + * May be used for NMI interrupt lines, and so may be called in IRQ or NMI + * context. */ void handle_percpu_devid_irq(struct irq_desc *desc) { @@ -930,7 +934,8 @@ void handle_percpu_devid_irq(struct irq_desc *desc) enabled ? " and unmasked" : "", irq, cpu); } =20 - add_interrupt_randomness(irq); + if (!in_nmi()) + add_interrupt_randomness(irq); =20 if (chip->irq_eoi) chip->irq_eoi(&desc->irq_data); --=20 2.30.2