From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail3-167.sinamail.sina.com.cn (mail3-167.sinamail.sina.com.cn [202.108.3.167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6C49D29D26B for ; Fri, 29 May 2026 23:28:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.108.3.167 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780097317; cv=none; b=eUhMMyjyog2Nqs2sJCVnNrS3h118K2QzziNQQ3Co47qzCLM1VCdGhPCsbpq+EdmYIFPEAKAM4mk7UmjyHxLu5pP7eHHPjdRofpLgO1bbPDkVW5i1GYcGSQrPw1VNdt6vSLj+5mnyJNPzW9U2TB8PEch3jo3uvudQmAC7jwUhzVg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780097317; c=relaxed/simple; bh=Rl+W9skjklZSKAy2nJnxKCrdbEChQn6otMV1lFgvbck=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=XliIYzZf0yddP5/qmPL3zYsDbIQcerXDU04D9baYC2/UU+ZW8KbVnZxDjRqSdCwXyikbQK5u5Crgybgrv+pckQQEZmXqvDg+m0ggo4W4oWpEXl3XXjHuOHnRzPdqKFMjmFTDByoepphgd+xr7rx+A5M2SNfPzFRMjrA2gUl5lQI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=sina.com; spf=pass smtp.mailfrom=sina.com; dkim=pass (1024-bit key) header.d=sina.com header.i=@sina.com header.b=BfZi7xjO; arc=none smtp.client-ip=202.108.3.167 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=sina.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=sina.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=sina.com header.i=@sina.com header.b="BfZi7xjO" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sina.com; s=201208; t=1780097314; bh=n5sSodDIv/OV6YYRYNNj3koRSJ2lm8111tQ+HkU1Mo4=; h=From:Subject:Date:Message-ID; b=BfZi7xjOjcOu1MvldUwEJ9zJcPCDaHLl7BhecTuZ14nuLtGJhmvfUYqPBZpGMdfc1 pw4NadFNIw6fFh5e+YGj6r3E1PJHxfmYJt6QFubReylc5Ce5UzO3a78++Vt/QGQsOH fV8VoDI3dKvQJzi44vt4MVElEPDC0hSqEZyf2TWY= X-SMAIL-HELO: localhost.localdomain Received: from unknown (HELO localhost.localdomain)([114.249.62.144]) by sina.com (10.54.253.33) with ESMTP id 6A1A211500007336; Fri, 30 May 2026 07:28:23 +0800 (CST) X-Sender: hdanton@sina.com X-Auth-ID: hdanton@sina.com Authentication-Results: sina.com; spf=none smtp.mailfrom=hdanton@sina.com; dkim=none header.i=none; dmarc=none action=none header.from=hdanton@sina.com X-SMAIL-MID: 8669136685212 X-SMAIL-UIID: 6002447360684DBD866C4BDAC9C55CD2-20260530-072823-1 From: Hillf Danton To: Sean Christopherson Cc: Waiman Long , Boqun Feng , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, David Woodhouse , Sebastian Andrzej Siewior , syzbot+208f7f3e5f59c11aeb90@syzkaller.appspotmail.com, Carsten Stollmaier Subject: Re: [PATCH v2 02/20] KVM: x86/xen: Use read_trylock() for GPC locks in hardirq/atomic paths Date: Sat, 30 May 2026 07:28:06 +0800 Message-ID: <20260529232812.1254-1-hdanton@sina.com> In-Reply-To: <20260529165114.748639-3-seanjc@google.com> References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On Fri, 29 May 2026 09:50:56 -0700 Sean Christopherson wrote: > From: David Woodhouse > > kvm_xen_set_evtchn_fast() is called from hardirq context (timer > callback, kvm_arch_set_irq_inatomic()). On PREEMPT_RT, rwlock_t is a > sleeping lock, so read_lock_irqsave() cannot be used in this context. > > Switch to read_trylock() and return -EWOULDBLOCK on contention, which is > the designed fallback — there is always a slow path for the case where > the GPC is invalid and needs to be refreshed. > > Reported-by: syzbot+208f7f3e5f59c11aeb90@syzkaller.appspotmail.com > Closes: https://syzkaller.appspot.com/bug?extid=208f7f3e5f59c11aeb90 > Fixes: 14243b387137 ("KVM: x86/xen: Add KVM_IRQ_ROUTING_XEN_EVTCHN and event channel delivery") > Signed-off-by: David Woodhouse > Signed-off-by: Sean Christopherson > --- > arch/x86/kvm/xen.c | 32 +++++++++++++++++++++++--------- > 1 file changed, 23 insertions(+), 9 deletions(-) > > diff --git a/arch/x86/kvm/xen.c b/arch/x86/kvm/xen.c > index 91fd3673c09a..9bdb8e3cad58 100644 > --- a/arch/x86/kvm/xen.c > +++ b/arch/x86/kvm/xen.c > @@ -697,6 +697,7 @@ void kvm_xen_inject_pending_events(struct kvm_vcpu *v) > int __kvm_xen_has_interrupt(struct kvm_vcpu *v) > { > struct gfn_to_pfn_cache *gpc = &v->arch.xen.vcpu_info_cache; > + bool atomic = in_atomic() || !task_is_running(current); > unsigned long flags; > u8 rc = 0; > > @@ -713,7 +714,15 @@ int __kvm_xen_has_interrupt(struct kvm_vcpu *v) > BUILD_BUG_ON(sizeof(rc) != > sizeof_field(struct compat_vcpu_info, evtchn_upcall_pending)); > > - read_lock_irqsave(&gpc->lock, flags); > + if (atomic) { > + local_irq_save(flags); > + if (!read_trylock(&gpc->lock)) { > + local_irq_restore(flags); > + return 1; > + } > + } else { > + read_lock_irqsave(&gpc->lock, flags); > + } > while (!kvm_gpc_check(gpc, sizeof(struct vcpu_info))) { > read_unlock_irqrestore(&gpc->lock, flags); > I suspect this works given static __always_inline void read_unlock_irqrestore(rwlock_t *rwlock, unsigned long flags) __releases_shared(rwlock) { rt_read_unlock(rwlock); }