From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 E26C0393DF1; Fri, 4 Sep 2026 14:54:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788533682; cv=none; b=Hty5Btyg9oFM2NsaiH4+NblTYKW4/T0BAHE9wmxBRlJpQr/RYoPVbvbd79yZtNzmhnNbEYHG3+InVwObHDB7k+kRA6vwudZinrWYfytTsUEyOvzebqTZL0mqfmB1yC90b9/i6WwlA3xj5LiZkQteX9UD49lrezdFF9teVN9E+uY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788533682; c=relaxed/simple; bh=Q+JDnlRSCW0BDvMmKpcvy7dgiXBS7TsdLb3fKiuLZow=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=qGA84cQ7FaOQe2Ndky2A2JIpACA+fUcemzIn3hVAPJZ9gZeIIV0JUpFgW1cPHOoXQ2R1B7Qshq869VA7U33nptUSjZAz28G6CO3bGBFLwYx341SzHNYJCEmp/FxgrZb1D0tCaSmP40rLvQjvwx3PrGRLXUJJgO8e0MLLEh1sSgk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=U2s7Ycjf; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="U2s7Ycjf" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 264BC1F00A3D; Fri, 4 Sep 2026 14:54:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788533679; bh=jWj3uM89dGfcaIeOwT5pkyubX8JmIb1Dz9DYUSqygQo=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=U2s7Ycjf+yMmOw6OYlIb2odTik+RSEfcf5loRPcFZ6Av1OeuuAar2RcnDm809qkyL ItL9iYMNOp+ZDDt0EwHcVYhO2VwowaACExuztAl7cIP0r46/FFIim3IfZMq5vkdhp7 Fu3q7zclqvYBbk1KsQ99nWei31ydMjgl0EgjXxIXec2PWrDgqDsGdlZXgpIERR9bud HtrcnSezcf8GRO0cFCeEsmcy5l3zW0W9qC2qBmOpT6Cs6R3hcSnUiPSfNjuL2ihJz1 KjMpWYCHDDa2/9y9DjvlOb4ENEcnWygZ2u5cZRx9xtMITIo9UV4XPYN2TWY0fz7H9n 7oFZnH81XQ8LA== Received: from sofa.misterjones.org ([185.219.108.64] helo=lobster-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1x2VJN-00000004uLv-137C; Fri, 04 Sep 2026 14:54:37 +0000 Date: Fri, 04 Sep 2026 15:57:11 +0100 Message-ID: <87se3p3vzs.wl-maz@kernel.org> From: Marc Zyngier To: Doug Anderson Cc: Thomas Gleixner , Mayank Rungta , Wim Van Sebroeck , Guenter Roeck , Radu Rendec , linux-watchdog@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, "Kirill A. Shutemov" Subject: Re: [PATCH v3 1/5] genirq: Synchronize in-flight handlers during NMI teardown In-Reply-To: References: <20260902-qcom-wdt-nmi-series-v3-0-f3999362a9ea@google.com> <20260902-qcom-wdt-nmi-series-v3-1-f3999362a9ea@google.com> <87fqzp8jex.ffs@fw13> <87wlt13zj1.wl-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: dianders@chromium.org, tglx@kernel.org, mrungta@google.com, wim@linux-watchdog.org, linux@roeck-us.net, radu@rendec.net, linux-watchdog@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, kas@kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Hey Doug, On Fri, 04 Sep 2026 15:34:12 +0100, Doug Anderson wrote: >=20 > Hi, >=20 > On Fri, Sep 4, 2026 at 6:38=E2=80=AFAM Marc Zyngier wrot= e: > > > > On Fri, 04 Sep 2026 10:17:42 +0100, > > Thomas Gleixner wrote: > > > > > > NMIs are strictly per CPU interrupts. So how is this supposed to work > > > correctly when looking at irqchip_state(ACTIVE) ? > > > > > > Marc? > > > > I have no idea what this is trying to achieve. > > > > This can only work for a global interrupt, not for a CPU-private > > interrupt, since in general you can't observe the state of the > > interrupt on another CPU. > > > > My guess is that the OP is trying to trigger an NMI using a global > > interrupt, which we never intended to be supported. That's not to say > > that it cannot be supported, but this patch seems to be breaking the > > core use case... >=20 > The overall goal is to take the watchdog bark interrupt (which is a > GIC Shared Peripheral Interrupt) and promote it to NMI. An example of > that interrupt in the device tree for one Qualcomm board: >=20 > interrupts =3D ; >=20 > The patches in this series seem to accomplish that. With the current > arm64 pseudo-NMI implemnttion, requesting as NMI just bumps up the > priority of an interrupt to "NMI" level and that works fine on SPIs as > well. On arm64/GIC interrupts are routed to a single CPU anyway, so > requesting it with `IRQF_PERCPU | IRQF_NOBALANCING` didn't seem > absurd. Not absurd, but the implementation as suggested has the potential to break per-CPU NMIs if you check for the active state on the wrong CPU. Also, checking for that state doesn't mean the kernel is free of reference on this interrupt, as you look at the HW state, not the kernel's. > The biggest problem we had was properly cleaning up the NMI at module > "unload" time. To make that work, we needed a way to synchronize the > NMIs to ensure they were quiescent before the module was unloaded. > That's what this patch is attempting, and is mostly attempting to > respond to Sashiko feedback on earlier patches. > > I don't think Mayank is tied to any particular implementation and the > overall goal here is to allow the watchdog bark interrupt to run at an > elevated level so it can produce good backtraces even if all the CPUs > in the system are locked up and the buddy lockup detector doesn't > fire. Is this something you think should be doable? If so, what's the > best way for Mayank to go about doing it? The only thing I can think of right now is some equivalent to IRQD_IRQ_INPROGRESS done in a lockless manner. It doesn't have to be atomic if you can guarantee that it is checked on the target CPU only, after having disabled the interrupt. But this is rather ugly, and I'm pretty sure Thomas will haete this just as much. M. --=20 Jazz isn't dead. It just smells funny.