intel_lpe_audio_irq_handler() forwards the LPE audio child IRQ from the
i915 parent IRQ path with generic_handle_irq(). The forwarded child top
half is not an independent hardirq entry point; it inherits the context
of the outer i915 interrupt dispatch path.

This becomes a problem when the parent IRQ runs in threaded context, for
example on PREEMPT_RT or other forced-threading configurations. i915
requests the parent IRQ with IRQF_SHARED and without IRQF_NO_THREAD, so
the forwarded child handler can run with local IRQs enabled. That
violates the expected top-half execution semantics and can trigger an
"enabled interrupts" WARN.

The issue was identified on Linux v6.18.21 by our static analysis tool
and then manually reviewed on the i915 child-IRQ forwarding sites after
commit 8cadce97bf26 ("drm/i915/gsc: mei interrupt top half should be in
irq disabled context") fixed the same helper contract for the GSC path.

It was then validated with a reproducible QEMU no-device parent/child
IRQ harness that registers a threaded parent IRQ and a child IRQ
handler, then exercises both generic_handle_irq() and
generic_handle_irq_safe() under the same threaded parent context. In the
plain-helper phase, the child handler ran with irqs_disabled=0 and
triggered an "enabled interrupts" WARN. In the safe-helper phase, the
same child handler ran with irqs_disabled=1. This is family-level
runtime evidence for the same IRQ forwarding misuse pattern. No
Baytrail/Cherrytrail hardware was available to run the real i915 LPE
path end-to-end.

Use generic_handle_irq_safe() here so the forwarded LPE audio child IRQ
runs with local IRQs disabled even when the outer i915 dispatch path is
threaded.

Fixes: eef57324d926 ("drm/i915: setup bridge for HDMI LPE audio driver")
Cc: stable@vger.kernel.org
Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn>
---
 drivers/gpu/drm/i915/display/intel_lpe_audio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_lpe_audio.c b/drivers/gpu/drm/i915/display/intel_lpe_audio.c
index 42284e9928f2..ac1dfd592a9f 100644
--- a/drivers/gpu/drm/i915/display/intel_lpe_audio.c
+++ b/drivers/gpu/drm/i915/display/intel_lpe_audio.c
@@ -263,7 +263,7 @@ void intel_lpe_audio_irq_handler(struct intel_display *display)
 	if (!HAS_LPE_AUDIO(display))
 		return;
 
-	ret = generic_handle_irq(display->audio.lpe.irq);
+	ret = generic_handle_irq_safe(display->audio.lpe.irq);
 	if (ret)
 		drm_err_ratelimited(display->drm,
 				    "error handling LPE audio irq: %d\n", ret);
-- 
2.34.1

On 2026-05-28 23:45:51 [+0800], Runyu Xiao wrote:
> intel_lpe_audio_irq_handler() forwards the LPE audio child IRQ from the
> i915 parent IRQ path with generic_handle_irq(). The forwarded child top
> half is not an independent hardirq entry point; it inherits the context
> of the outer i915 interrupt dispatch path.
…

This looks very familiar and is work in progress
	https://lore.kernel.org/all/20260310115709.2276203-16-dev@lankhorst.se/

Maarten, where do we stand on the i915 series?

> Fixes: eef57324d926 ("drm/i915: setup bridge for HDMI LPE audio driver")
> Cc: stable@vger.kernel.org

No stable fix needed because i915 can not be turned on PREEMPT_RT.

Sebastian

Hey,

Den 2026-05-29 kl. 09:48, skrev Sebastian Andrzej Siewior:
> On 2026-05-28 23:45:51 [+0800], Runyu Xiao wrote:
>> intel_lpe_audio_irq_handler() forwards the LPE audio child IRQ from the
>> i915 parent IRQ path with generic_handle_irq(). The forwarded child top
>> half is not an independent hardirq entry point; it inherits the context
>> of the outer i915 interrupt dispatch path.
> …
> 
> This looks very familiar and is work in progress
> 	https://lore.kernel.org/all/20260310115709.2276203-16-dev@lankhorst.se/
> 
> Maarten, where do we stand on the i915 series?
> 
>> Fixes: eef57324d926 ("drm/i915: setup bridge for HDMI LPE audio driver")
>> Cc: stable@vger.kernel.org
> 
> No stable fix needed because i915 can not be turned on PREEMPT_RT.
> 
> Sebastian

It's been absolutely rock stable since the last time I submitted it.
I've been using it on my local machine, and the amount of times >100us
(evasion failed) with and without PREEMPT_RT are identical with
the vblank changes.
It still applies cleanly when rebasing.

The vblank patches are the most involved change, and they ensure that
absolutely no lock contention happens in the critical path with irqs off.

Unfortunately the status is still same as the time I submitted it before it,
and pending reviews on the series.

Kind regards,
~Maarten Lankhorst

On 2026-05-29 11:50:18 [+0200], Maarten Lankhorst wrote:
> Hey,
Hi,

> It's been absolutely rock stable since the last time I submitted it.
> I've been using it on my local machine, and the amount of times >100us
> (evasion failed) with and without PREEMPT_RT are identical with
> the vblank changes.
> It still applies cleanly when rebasing.
> 
> The vblank patches are the most involved change, and they ensure that
> absolutely no lock contention happens in the critical path with irqs off.

So that is the good part.

> Unfortunately the status is still same as the time I submitted it before it,
> and pending reviews on the series.

my memory is that you have no work items and the auto-CI isn't worse
than before. The series just waits for a review then?

> Kind regards,
> ~Maarten Lankhorst

Sebastian

Thanks Sebastian and Maarten.

I understand this fix is already covered by Maarten's i915 PREEMPT_RT
series and that the series is still pending review.

I'll drop this standalone patch and won't pursue a stable-targeted
version.

This issue was independently found by our static analysis and validated
with a no-device QEMU harness. If the extra analysis or validation
details are useful for the ongoing series, I can share them separately.

Best regards,
Runyu

On Fri, 29 May 2026, Runyu Xiao <runyu.xiao@seu.edu.cn> wrote:
> Thanks Sebastian and Maarten.
>
> I understand this fix is already covered by Maarten's i915 PREEMPT_RT
> series and that the series is still pending review.
>
> I'll drop this standalone patch and won't pursue a stable-targeted
> version.

IMO merging easy to review standalone patches helps make progress while
the more contentious changes are in, well, sort of review limbo.

BR,
Jani.

>
> This issue was independently found by our static analysis and validated
> with a no-device QEMU harness. If the extra analysis or validation
> details are useful for the ongoing series, I can share them separately.
>
> Best regards,
> Runyu

-- 
Jani Nikula, Intel

Thanks, Jani.

That makes sense. I'll keep this as a standalone patch and respin it
without the stable tag.

Maarten, I understand the same fix is also present in your PREEMPT_RT
series. If you think it would be helpful, I can add a Link: tag to that
series in the next revision to make the overlap explicit.

Best regards,
Runyu

intel_lpe_audio_irq_handler() forwards the LPE audio child IRQ from the
i915 parent IRQ path with generic_handle_irq(). The forwarded child top
half is not an independent hardirq entry point; it inherits the context
of the outer i915 interrupt dispatch path.

This becomes a problem when the parent IRQ runs in threaded context, for
example on PREEMPT_RT or other forced-threading configurations. i915
requests the parent IRQ with IRQF_SHARED and without IRQF_NO_THREAD, so
the forwarded child handler can run with local IRQs enabled. That
violates the expected top-half execution semantics and can trigger an
"enabled interrupts" WARN.

The issue was identified on Linux v6.18.21 by our static analysis tool
and then manually reviewed on the i915 child-IRQ forwarding sites after
commit 8cadce97bf26 ("drm/i915/gsc: mei interrupt top half should be in
irq disabled context") fixed the same helper contract for the GSC path.

It was then validated with a reproducible QEMU no-device parent/child
IRQ harness that registers a threaded parent IRQ and a child IRQ
handler, then exercises both generic_handle_irq() and
generic_handle_irq_safe() under the same threaded parent context. In the
plain-helper phase, the child handler ran with irqs_disabled=0 and
triggered an "enabled interrupts" WARN. In the safe-helper phase, the
same child handler ran with irqs_disabled=1. This is family-level
runtime evidence for the same IRQ forwarding misuse pattern. No
Baytrail/Cherrytrail hardware was available to run the real i915 LPE
path end-to-end.

Use generic_handle_irq_safe() here so the forwarded LPE audio child IRQ
runs with local IRQs disabled even when the outer i915 dispatch path is
threaded.

Link: https://lore.kernel.org/all/20260310115709.2276203-16-dev@lankhorst.se/
Fixes: eef57324d926 ("drm/i915: setup bridge for HDMI LPE audio driver")
Suggested-by: Maarten Lankhorst <dev@lankhorst.se>
Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn>
---
v2:
- Add Link: tag to Maarten's PREEMPT_RT series
- Add Suggested-by: Maarten Lankhorst
- Drop Cc: stable@vger.kernel.org per Sebastian's feedback
- Keep as a standalone patch per Jani's suggestion

 drivers/gpu/drm/i915/display/intel_lpe_audio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_lpe_audio.c b/drivers/gpu/drm/i915/display/intel_lpe_audio.c
index 42284e9928f2..ac1dfd592a9f 100644
--- a/drivers/gpu/drm/i915/display/intel_lpe_audio.c
+++ b/drivers/gpu/drm/i915/display/intel_lpe_audio.c
@@ -263,7 +263,7 @@ void intel_lpe_audio_irq_handler(struct intel_display *display)
 	if (!HAS_LPE_AUDIO(display))
 		return;
 
-	ret = generic_handle_irq(display->audio.lpe.irq);
+	ret = generic_handle_irq_safe(display->audio.lpe.irq);
 	if (ret)
 		drm_err_ratelimited(display->drm,
 				    "error handling LPE audio irq: %d\n", ret);
-- 
2.34.1

On 2026-05-31 23:31:08 [+0800], Runyu Xiao wrote:
> intel_lpe_audio_irq_handler() forwards the LPE audio child IRQ from the
> i915 parent IRQ path with generic_handle_irq(). The forwarded child top
> half is not an independent hardirq entry point; it inherits the context
> of the outer i915 interrupt dispatch path.
…
> 
> Link: https://lore.kernel.org/all/20260310115709.2276203-16-dev@lankhorst.se/
> Fixes: eef57324d926 ("drm/i915: setup bridge for HDMI LPE audio driver")
> Suggested-by: Maarten Lankhorst <dev@lankhorst.se>
> Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn>

If you want to send this as an individual patch, please take Maarten
original patch, add your signed-off by below and send it while keeping
him as Author.

Sebastian