On Mon, Sep 21, 2026 at 1:21 PM Hillf Danton <[email protected]> wrote: > > On Mon, 21 Sep 2026 11:54:36 +0200 David Woodhouse wrote: > > On Mon, 2026-09-21 at 09:42 +0800, Hillf Danton wrote: > > > On Sun, 20 Sep 2026 21:49:29 +0100 David Woodhouse wrote: > > > > > > > > Replace the per-cache rwlock with a dedicated per-VM atomic SRCU > > > > domain (kvm->gpc_srcu) for the read side. Readers now run under > > > > srcu_read_lock_atomic() alone — preemption disabled and non-blocking > > > > enforced, which every GPC read-side section already satisfied as a > > > > former rwlock critical section. It works in any context > > > > (including hardirq and sched-out paths) and never fails or spins, > > > > eliminating the > > > > read_trylock() contortions in the atomic paths, the double-lock dance > > > > with the lockdep subclass hack in the runstate update, and the > > > > PREEMPT_RT problems inherent to taking an rwlock in those contexts. > > > > In particular, kvm_xen_set_evtchn_fast() is called from hardirq > > > > context (timer callback, kvm_arch_set_irq_inatomic()), where taking > > > > gpc->lock is a sleeping-lock-in-atomic-context bug on PREEMPT_RT. > > > > > > Given the preempt_disable() in srcu_read_lock_atomic(), as PREEMPT_RT > > > has no way of handling preempt_disable(), you need to add another > > > version of srcu_read_lock_atomic() with preempt_disable() replaced with > > > something like rcu_read_lock(). > > > > Hm? What's wrong with preempt_disable()? It works OK, but is generally > > How is preempt_disable() handled by RT?
It disables preemption. :) The difference is that *spinlocks* (by virtue of becoming sleeping locks) do not disable it, but the low-level primitives preempt_disable and get_cpu do not change their behavior. Older PREEMPT_RT patches had get_cpu_light() which did migrate_disable() instead of preempt_disable(), but then migrate_disable() was deprecated. Paolo
