From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from canpmsgout10.his.huawei.com (canpmsgout10.his.huawei.com [113.46.200.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 023E93C1405 for ; Thu, 7 May 2026 11:38:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.225 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778153931; cv=none; b=OKKAnakLEdvuQOK81O+j73LpPhOcFWn1Gx80lzqtm0BwKQeRVaHxaqUkEzPflpomnRn+EI8Vs0Zj8ezLwDFjH6+SUINt0wGCPd5ZcOarhIHyPWNk2EopUEq878WaaqTWqhw7ibWSsz3MdaxulFem/3ApbLHZFNL29aeYIBw2cA8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778153931; c=relaxed/simple; bh=fpVu4tVWF8MW0F4k4vZxwPP9OUiIcKhN9EWARJAEK+k=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=JVAHewyE/uOy+RjnJT1mFUH+QUgcd2dWSJDzfRT8u8B5F/NDaut+8TkaecgkZV9HBnCAF04IvkcM7NBUkmm9nATv3SZHFj9v8UGFv9TLnPqmcfO7+v0NHCO7F5hMaS44fjuiPsNXLoJgO3+UpDV/fGCSZWAUSkjehUaF88JK1Fo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=gchs4iZY; arc=none smtp.client-ip=113.46.200.225 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="gchs4iZY" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=bl8NI7iyWc+PLlC7zgcc6VA1wfrCDz0bxICRMic41gY=; b=gchs4iZYRiy62Qo8Hog1ZBKBCv1BqKlHBFvWw4cfu/Mn+4vpVp5V2w6mVFnh33jt3ZyCg7zfr 60oQqpSX9roNzKv7Ep9P6NTqfff0r1EksLArgwXsqikFxaZuvfkKs9bycRaN7lqfFaQ2A1w8ExL xhoAHpjV/Y+7X2S0rsUNSxM= Received: from mail.maildlp.com (unknown [172.19.163.214]) by canpmsgout10.his.huawei.com (SkyGuard) with ESMTPS id 4gB9703868z1K9Bd; Thu, 7 May 2026 19:31:08 +0800 (CST) Received: from dggpemf500011.china.huawei.com (unknown [7.185.36.131]) by mail.maildlp.com (Postfix) with ESMTPS id 8A8F04056C; Thu, 7 May 2026 19:38:40 +0800 (CST) Received: from [10.67.109.254] (10.67.109.254) by dggpemf500011.china.huawei.com (7.185.36.131) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Thu, 7 May 2026 19:38:39 +0800 Message-ID: Date: Thu, 7 May 2026 19:38:40 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] genirq/chip: Don't call add_interrupt_randomness() for NMIs To: Mark Rutland , , Thomas Gleixner CC: , , , , References: <20260507110518.3128248-1-mark.rutland@arm.com> From: Jinjie Ruan In-Reply-To: <20260507110518.3128248-1-mark.rutland@arm.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-ClientProxiedBy: kwepems200002.china.huawei.com (7.221.188.68) To dggpemf500011.china.huawei.com (7.185.36.131) On 5/7/2026 7:05 PM, Mark Rutland wrote: > 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. > >     ================================ >     WARNING: inconsistent lock state >     7.1.0-rc2-pnmi #465 Not tainted >     -------------------------------- >     inconsistent {INITIAL USE} -> {IN-NMI} usage. >     perf/695 [HC1[1]:SC0[0]:HE0:SE1] takes: >     ffff00837dfd3a18 (&base->lock){-.-.}-{2:2}, at: lock_timer_base+0x6c/0xac >     {INITIAL USE} state was registered at: >       lock_acquire+0x260/0x40c >       _raw_spin_lock_irqsave+0x68/0xb0 >       lock_timer_base+0x6c/0xac >       __mod_timer+0x100/0x32c >       add_timer_global+0x2c/0x40 >       __queue_delayed_work+0xf0/0x140 >       queue_delayed_work_on+0x134/0x138 >       mem_cgroup_css_online+0x30c/0x310 >       online_css+0x34/0x10c >       cgroup_init_subsys+0x158/0x1c8 >       cgroup_init+0x440/0x524 >       start_kernel+0x888/0x998 >       __primary_switched+0x88/0x90 >     irq event stamp: 62068 >     hardirqs last  enabled at (62067): [] seqcount_lockdep_reader_access.constprop.0+0xf0/0xfc >     hardirqs last disabled at (62068): [] _raw_spin_lock_irqsave+0x94/0xb0 >     softirqs last  enabled at (62050): [] put_cpu_fpsimd_context+0x1c/0x4c >     softirqs last disabled at (62048): [] get_cpu_fpsimd_context+0x1c/0x4c >         other info that might help us debug this: >     Possible unsafe locking scenario: >            CPU0 >            ---- >       lock(&base->lock); >       >         lock(&base->lock); >         *** DEADLOCK *** >     3 locks held by perf/695: >      #0: ffff0080146cd2c8 (&type->i_mutex_dir_key#6){++++}-{4:4}, at: lookup_slow+0x30/0x68 >      #1: ffff80008332b858 (rcu_read_lock){....}-{1:3}, at: blk_mq_run_hw_queue+0xf4/0x1fc >      #2: ffff008000b6aa18 (&host->lock){-.-.}-{3:3}, at: ata_scsi_queuecmd+0x28/0x88 >     stack backtrace: >     CPU: 3 UID: 0 PID: 695 Comm: perf Not tainted 7.1.0-rc2-pnmi #465 PREEMPT >     Hardware name: ARM LTD Morello System Development Platform, BIOS EDK II Mar  7 2024 >     Call trace: >      show_stack+0x18/0x24 (C) >      dump_stack_lvl+0xc4/0x148 >      dump_stack+0x18/0x24 >      print_usage_bug.part.0+0x29c/0x364 >      lock_acquire+0x364/0x40c >      _raw_spin_lock_irqsave+0x68/0xb0 >      lock_timer_base+0x6c/0xac >      add_timer_on+0x78/0x16c >      add_interrupt_randomness+0x124/0x134 >      handle_percpu_devid_irq+0xd4/0x16c >      handle_irq_desc+0x40/0x58 >      generic_handle_domain_nmi+0x28/0x50 >      __gic_handle_nmi.isra.0+0x4c/0xa0 >      gic_handle_irq+0x38/0x2bc >      call_on_irq_stack+0x30/0x48 >      do_interrupt_handler+0x80/0x98 >      el1_interrupt+0x90/0xac >      el1h_64_irq_handler+0x18/0x24 >      el1h_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 handle_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 > --- > 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 > > #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); > } > > - add_interrupt_randomness(irq); > + if (!in_nmi()) > + add_interrupt_randomness(irq); Reviewed-by: Jinjie Ruan > > if (chip->irq_eoi) > chip->irq_eoi(&desc->irq_data);