Re: [PATCH] KVM: x86/xen: bail in IRQ context on PREEMPT_RT in kvm_xen_set_evtchn_fast()

[Sebastian Andrzej Siewior <bigeasy@linutronix.de>]

On 2026-05-07 14:43:20 [+0100], David Woodhouse wrote:
> Thanks. Something like this?

Yes. If you could stuff the below into the patch so it does not look
like fixing symptoms.

> From 7199173d543d25333418537bcf07d6b2fce18ff1 Mon Sep 17 00:00:00 2001
> From: David Woodhouse <dwmw@amazon.co.uk>
> Date: Thu, 7 May 2026 14:39:22 +0100
> Subject: [PATCH] locking/rt: Use raw_spin_lock_irqsave() in
>  __rwbase_read_unlock()
> 
> __rwbase_read_unlock() uses raw_spin_lock_irq()/raw_spin_unlock_irq()
> which unconditionally disables and re-enables interrupts. When
> read_unlock() is called from hardirq context (e.g. after a successful
> read_trylock() in a timer callback), the raw_spin_unlock_irq()
> incorrectly re-enables interrupts within the hardirq handler.
> 
> This causes lockdep warnings ('hardirqs_on_prepare' from hardirq
> context) and can lead to IRQ state corruption.

Using read_trylock() in hardirq context on PREEMPT_RT is safe because it
does not record the lock owner. The read_unlock() acquires the wait_lock
which is hardirq safe. This change additionally allows rwlock_t during
early boot.

> 
> Switch to raw_spin_lock_irqsave()/raw_spin_unlock_irqrestore() to
> preserve the caller's IRQ state, matching the pattern already used
> for rt_spin_lock/unlock.
> 
> Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>

Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>

Sebastian