From nobody Tue Apr 7 06:19:58 2026 Received: from mail-ot1-f69.google.com (mail-ot1-f69.google.com [209.85.210.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EFDBC155C82 for ; Sun, 15 Mar 2026 15:07:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.69 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773587275; cv=none; b=JPZuTfUN8Gq6tpOZUR9rTLQ89JXjE+7lmG37+qEySkiNDaAVxaEC91OE5hJRt3Xp5Ksk09pzR6o0gj+olcSmW62x4lETk3kL3LEY0AJsqk9vqsPRb0j4PaHfOv19oCJOjq8fTC4P+KW4Dx7TQqxVac9rLJRdQ+i4J7FTNb7++VM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773587275; c=relaxed/simple; bh=WLEb6OOt1AThVJH3URhdRLyUiM8ViE8AoQCJ9i54Y38=; h=MIME-Version:Date:In-Reply-To:Message-ID:Subject:From:To: Content-Type; b=GgWXgjbCcsQ6vXgSKRs7sYaLuPMIa4oyySLaQbFK7AaMY0OoDePXa3U7mrXrPJYPt8z4IjmFcq0lR6TxRx7DqpjV6lcOIUYbpuTaZ6r2u6a3QQMBvVhJv9Wlo0htcFHfL3gvR1/bBQ1NHB/dJ75aoaE07TF+WwuockSVHXd88bs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=syzkaller.appspotmail.com; spf=pass smtp.mailfrom=M3KW2WVRGUFZ5GODRSRYTGD7.apphosting.bounces.google.com; arc=none smtp.client-ip=209.85.210.69 Authentication-Results: smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=syzkaller.appspotmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=M3KW2WVRGUFZ5GODRSRYTGD7.apphosting.bounces.google.com Received: by mail-ot1-f69.google.com with SMTP id 46e09a7af769-7d742bb4003so15884746a34.0 for ; Sun, 15 Mar 2026 08:07:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773587273; x=1774192073; h=to:from:subject:message-id:in-reply-to:date:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=WLEb6OOt1AThVJH3URhdRLyUiM8ViE8AoQCJ9i54Y38=; b=BwVqEkkanF8E5y5PNoBUuDWQtdtMiWlj40BAXMov9s/Lkmat61+I7gJqFbKt0MHjun dEi71u+7/BhcToESgL3jPoW3zkMGPg5jX5DeYHGlzUXdGUmfkh6foGb4j+ij+/UuJYXu c0Z2ODVDXcNWmx8lqjgDTCwoh5wZs2l7OH3Mto5FATt/5OpJKMPlCrgCokrxDfZHE2C3 xgm4a8vy5Y3qRToLI51+jkSkuQQIiJgDtNZm2FH0KFUYlS5JKL6OeIYhUdaA69YwAE7y RXomAAAzagbsxQ1947UO159OfES5jIBAZKhwB+OYENINBvyALMvLggC6AcqgkLtDysTz jfdA== X-Gm-Message-State: AOJu0YyG+8jiCT/rRq33S9rJbyJGV/2i7ufwyAjQAXJ1KPiUYtaDqPmQ hC6El9ek0RHHM5cRQGTY40cPfCDvVrFOxMVkw4I4mUZpYJxsm6/0ciSD8hkoPIEl6bDOrD/QkSx 8xn7jD+SQbjf64GED7SLFi34djCrHz8iftn+w+xkXtAmKEGyVml4tkQt/uWg= Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Received: by 2002:a05:6820:f004:b0:67b:bdc5:cc96 with SMTP id 006d021491bc7-67bda9c0a3fmr6407363eaf.23.1773587272940; Sun, 15 Mar 2026 08:07:52 -0700 (PDT) Date: Sun, 15 Mar 2026 08:07:52 -0700 In-Reply-To: <673f4bbc.050a0220.3c9d61.0174.GAE@google.com> X-Google-Appengine-App-Id: s~syzkaller X-Google-Appengine-App-Id-Alias: syzkaller Message-ID: <69b6cb48.050a0220.12d28.0155.GAE@google.com> Subject: Forwarded: (No Subject) From: syzbot To: linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" For archival purposes, forwarding an incoming command email to linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com. *** Subject: (No Subject) Author: zxcyui967@proton.me #syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git= master From kettlebellok Mon Sep 17 00:00:00 2001 From: kettlebellok Date: Wed, 12 Mar 2026 00:00:00 +0800 Subject: [PATCH] KVM: xen: fix sleeping lock in hardirq context in xen_timer_callback() xen_timer_callback() calls kvm_xen_set_evtchn_fast(), which acquires gpc->lock via read_lock_irqsave(). This is a regular rwlock, which becomes a sleeping lock on PREEMPT_RT kernels. Since xen_timer_callback() runs in hardirq context (hrtimer), this is invalid and triggers: BUG: Invalid wait context kvm_xen_set_evtchn_fast xen_timer_callback __hrtimer_run_queues hrtimer_interrupt Fix this by removing the kvm_xen_set_evtchn_fast() call from xen_timer_callback() and always deferring event delivery via the existing timer_pending mechanism. The vCPU will then deliver the event through kvm_xen_inject_timer_irqs() in a safe process context. This was already the fallback path when kvm_xen_set_evtchn_fast() returned -EWOULDBLOCK. Reported-by: syzbot+919877893c9d28162dc2@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=3D919877893c9d28162dc2 Signed-off-by: kettlebellok --- arch/x86/kvm/xen.c | 13 ------------- 1 file changed, 13 deletions(-) diff --git a/arch/x86/kvm/xen.c b/arch/x86/kvm/xen.c index 91fd3673c09a..e588a188f50a 100644 --- a/arch/x86/kvm/xen.c +++ b/arch/x86/kvm/xen.c @@ -126,23 +126,10 @@ static enum hrtimer_restart xen_timer_callback(struct= hrtimer *timer) { struct kvm_vcpu *vcpu =3D container_of(timer, struct kvm_vcpu, arch.xen.timer); - struct kvm_xen_evtchn e; - int rc; if (atomic_read(&vcpu->arch.xen.timer_pending)) return HRTIMER_NORESTART; - e.vcpu_id =3D vcpu->vcpu_id; - e.vcpu_idx =3D vcpu->vcpu_idx; - e.port =3D vcpu->arch.xen.timer_virq; - e.priority =3D KVM_IRQ_ROUTING_XEN_EVTCHN_PRIO_2LEVEL; - - rc =3D kvm_xen_set_evtchn_fast(&e, vcpu->kvm); - if (rc !=3D -EWOULDBLOCK) { - vcpu->arch.xen.timer_expires =3D 0; - return HRTIMER_NORESTART; - } - atomic_inc(&vcpu->arch.xen.timer_pending); kvm_make_request(KVM_REQ_UNBLOCK, vcpu); kvm_vcpu_kick(vcpu); -- 2.43.0