[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <95fbade0e6e304c207f1a4906fc8f3475eb8785a.camel@siemens.com>
Date: Thu, 5 Feb 2026 14:12:21 +0000
From: "Bezdeka, Florian" <florian.bezdeka@...mens.com>
To: "kys@...rosoft.com" <kys@...rosoft.com>, "decui@...rosoft.com"
<decui@...rosoft.com>, "bp@...en8.de" <bp@...en8.de>, "longli@...rosoft.com"
<longli@...rosoft.com>, "dave.hansen@...ux.intel.com"
<dave.hansen@...ux.intel.com>, "mingo@...hat.com" <mingo@...hat.com>,
"wei.liu@...nel.org" <wei.liu@...nel.org>, "tglx@...nel.org"
<tglx@...nel.org>, "Kiszka, Jan" <jan.kiszka@...mens.com>,
"haiyangz@...rosoft.com" <haiyangz@...rosoft.com>, "x86@...nel.org"
<x86@...nel.org>
CC: "linux-rt-users@...r.kernel.org" <linux-rt-users@...r.kernel.org>,
"linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"levymitchell0@...il.com" <levymitchell0@...il.com>
Subject: Re: [PATCH] x86: mshyperv: Use kthread for vmbus interrupts on
PREEMPT_RT
On Tue, 2026-02-03 at 17:01 +0100, Jan Kiszka wrote:
> From: Jan Kiszka <jan.kiszka@...mens.com>
>
> Resolves the following lockdep report when booting PREEMPT_RT on Hyper-V
> with related guest support enabled:
>
> [ 1.127941] hv_vmbus: registering driver hyperv_drm
>
> [ 1.132518] =============================
> [ 1.132519] [ BUG: Invalid wait context ]
> [ 1.132521] 6.19.0-rc8+ #9 Not tainted
> [ 1.132524] -----------------------------
> [ 1.132525] swapper/0/0 is trying to lock:
> [ 1.132526] ffff8b9381bb3c90 (&channel->sched_lock){....}-{3:3}, at: vmbus_chan_sched+0xc4/0x2b0
> [ 1.132543] other info that might help us debug this:
> [ 1.132544] context-{2:2}
> [ 1.132545] 1 lock held by swapper/0/0:
> [ 1.132547] #0: ffffffffa010c4c0 (rcu_read_lock){....}-{1:3}, at: vmbus_chan_sched+0x31/0x2b0
> [ 1.132557] stack backtrace:
> [ 1.132560] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.19.0-rc8+ #9 PREEMPT_{RT,(lazy)}
> [ 1.132565] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/25/2025
> [ 1.132567] Call Trace:
> [ 1.132570] <IRQ>
> [ 1.132573] dump_stack_lvl+0x6e/0xa0
> [ 1.132581] __lock_acquire+0xee0/0x21b0
> [ 1.132592] lock_acquire+0xd5/0x2d0
> [ 1.132598] ? vmbus_chan_sched+0xc4/0x2b0
> [ 1.132606] ? lock_acquire+0xd5/0x2d0
> [ 1.132613] ? vmbus_chan_sched+0x31/0x2b0
> [ 1.132619] rt_spin_lock+0x3f/0x1f0
> [ 1.132623] ? vmbus_chan_sched+0xc4/0x2b0
> [ 1.132629] ? vmbus_chan_sched+0x31/0x2b0
> [ 1.132634] vmbus_chan_sched+0xc4/0x2b0
> [ 1.132641] vmbus_isr+0x2c/0x150
> [ 1.132648] __sysvec_hyperv_callback+0x5f/0xa0
> [ 1.132654] sysvec_hyperv_callback+0x88/0xb0
> [ 1.132658] </IRQ>
> [ 1.132659] <TASK>
> [ 1.132660] asm_sysvec_hyperv_callback+0x1a/0x20
>
> As code paths that handle vmbus IRQs use sleepy locks under PREEMPT_RT,
> the complete vmbus_handler execution needs to be moved into thread
> context. Open-coding this allows to skip the IPI that irq_work would
> additionally bring and which we do not need, being an IRQ, never an NMI.
>
> Signed-off-by: Jan Kiszka <jan.kiszka@...mens.com>
Tested-by: Florian Bezdeka <florian.bezdeka@...mens.com>
This patch survived a 24h stress test with CONFIG_PREEMPT_RT enabled and
heavy load applied to the system.
There was no lockup happening without this patch. The lockdep warning is
gone now.
Best regards,
Florian
--
Siemens AG, Foundational Technologies
Linux Expert Center
Powered by blists - more mailing lists