Forwarded: Re: [PATCH] KVM: x86/xen: Use read_trylock() for GPC locks in hardirq paths

[syzbot <syzbot+919877893c9d28162dc2@syzkaller.appspotmail.com>]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: Re: [PATCH] KVM: x86/xen: Use read_trylock() for GPC locks in hardirq paths
Author: dwmw2@infradead.org

On Fri, 2026-08-07 at 17:49 +0530, sai madhu wrote:
> kvm_xen_set_evtchn_fast() is called from hardirq context (xen timer
> callback, kvm_arch_set_irq_inatomic()). On PREEMPT_RT (and under
> lockdep), read_lock_irqsave(&gpc->lock) is invalid there because
> rwlock_t may sleep.
> 
> Switch to read_trylock() and return -EWOULDBLOCK when the lock is
> contended or the cache is invalid. xen_timer_callback() already
> defers to the slow path (timer_pending + KVM_REQ_UNBLOCK +
> kvm_xen_inject_timer_irqs()).
> 
> Also fix __kvm_xen_has_interrupt() the same way for atomic callers.
> 
> Based on David Woodhouse's upstream series (May 2026, patch 3/7).
> Fixes syzbot: https://syzkaller.appspot.com/bug?extid=919877893c9d28162dc2

Thanks... but why? We're literally iterating on this right now.

I'm fairly convinced I want to ditch rwlocks completely and move to RCU:
https://lore.kernel.org/all/20260805195528.3853473-1-dwmw@amazon.co.uk/

Testing found some issues in my conversion which I've since fixed, and
the conversion to SRCU at Sean's request is currently an *incremental*
patch, which I'll eventually squash back into the first.

I'm in the middle of running a weekend-long soak test on this tree:
https://git.infradead.org/?p=users/dwmw2/linux.git;a=shortlog;h=refs/heads/xen-rcu-fixed

Let's see what syzbot thinks of it...

#syz test: git://git.infradead.org/users/dwmw2/linux.git xen-rcu-fixed