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

[Sebastian Andrzej Siewior]

On 2026-05-07 14:00:49 [+0100], David Woodhouse wrote:
> On Thu, 2026-05-07 at 09:12 +0200, Sebastian Andrzej Siewior wrote:
> > 
> > So the cited patch does not look bad. That read-trylock should be fine
> > on RT (as in I don't see anything wrong with it). What did happen to it?
> 
> The read_trylock() may be fine... but does a read_unlock() try to
> "re-enable" hardirqs?

Yes, I missed it while looking for it. This could become a _irqsave().

We do this already for spinlock_t/ rt_spin_lock()/ _unlock() because it
is used during early boot where interrupts are disabled and locks are
acquired. So it needs to preserve the state and since rwlock_t is not
(yet) used during early boot it was not done/ observed.

The try-lock on the read lock just increments a counter in order to
acquire the lock. This is it. The spinlock_t on the other hand records
the current context as owner which can lead to a mess. Therefore a
trylock on a spinlock_t from hardirq context is wrong but it should be
doable for rwlock_t. I don't see anything wrong with it (except for this
one thing can be corrected).

Sebastian