linux-kernel - Re: [PATCH 0/5] Drivers: hv: Fix NEED_RESCHED

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aK3nmOgVl4INJpjG@liuwe-devbox-ubuntu-v2.tail21d00.ts.net>
Date: Tue, 26 Aug 2025 16:58:00 +0000
From: Wei Liu <wei.liu@...nel.org>
To: Sean Christopherson <seanjc@...gle.com>
Cc: Nuno Das Neves <nunodasneves@...ux.microsoft.com>,
	Marc Zyngier <maz@...nel.org>,
	Oliver Upton <oliver.upton@...ux.dev>,
	Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will@...nel.org>,
	Tianrui Zhao <zhaotianrui@...ngson.cn>,
	Bibo Mao <maobibo@...ngson.cn>, Huacai Chen <chenhuacai@...nel.org>,
	Anup Patel <anup@...infault.org>,
	Paul Walmsley <paul.walmsley@...ive.com>,
	Palmer Dabbelt <palmer@...belt.com>,
	Albert Ou <aou@...s.berkeley.edu>,
	Paolo Bonzini <pbonzini@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
	Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
	"K. Y. Srinivasan" <kys@...rosoft.com>,
	Haiyang Zhang <haiyangz@...rosoft.com>,
	Wei Liu <wei.liu@...nel.org>, Dexuan Cui <decui@...rosoft.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Andy Lutomirski <luto@...nel.org>,
	"Paul E. McKenney" <paulmck@...nel.org>,
	Frederic Weisbecker <frederic@...nel.org>,
	Neeraj Upadhyay <neeraj.upadhyay@...nel.org>,
	Joel Fernandes <joelagnelf@...dia.com>,
	Josh Triplett <josh@...htriplett.org>,
	Boqun Feng <boqun.feng@...il.com>,
	Uladzislau Rezki <urezki@...il.com>, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, kvmarm@...ts.linux.dev,
	kvm@...r.kernel.org, loongarch@...ts.linux.dev,
	kvm-riscv@...ts.infradead.org, linux-riscv@...ts.infradead.org,
	linux-hyperv@...r.kernel.org, rcu@...r.kernel.org
Subject: Re: [PATCH 0/5] Drivers: hv: Fix NEED_RESCHED_LAZY and use common
 APIs

On Mon, Aug 25, 2025 at 05:27:16PM -0700, Sean Christopherson wrote:
> On Mon, Aug 25, 2025, Nuno Das Neves wrote:
> > On 8/25/2025 1:06 PM, Sean Christopherson wrote:
> > > Fix a bug where MSHV root partitions don't honor NEED_RESCHED_LAZY, and then
> > > deduplicate the TIF related MSHV code by turning the "kvm" entry APIs into
> > > more generic "virt" APIs (which ideally would have been done when MSHV root
> > > support was added).
> > > 
> > > Assuming all is well, maybe this could go through the tip tree?
> > > 
> > > The Hyper-V stuff and non-x86 architectures are compile-tested only.
> > > 
> > 
> > Thanks Sean, I can test the root partition changes.
> > 
> > A similar change will be needed in mshv_vtl_main.c since it also calls
> > mshv_do_pre_guest_mode_work() (hence the "common" in mshv_common.c).
> 
> Oof, more dependencies.  I suppose the easiest thing would be to send a series
> against
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux.git queue
> 
> and then route everything through there?

Our fixes branch is on 6.17-rc1. You can use it as a base if you want
to.

> 
> Alternatively, frontload the MSHV fixes (which I'll do regardless) and take those
> through hyperv and the rest through the tip tree?  That seems like an absurd
> amount of juggling though, especially if we want to get the cleanups into 6.18.
> And if none of these lands, it's MSHV that'll suffer the most, so betting it all
> on the hyperv tree doesn't seem terrible.
> 

I'm happy to do it however the community sees fit.

> > Also, is it possible to make all the mshv driver changes in a single patch?
> 
> It's certainly possible, but I'd prefer not do to that.
> 
> > It seems like it would be cleaner than refactoring it in patches 1 & 2 and
> > then deleting all the refactored code in patch 5.
> 
> Only if you don't care about backporting fixes, bisection, or maintaining code.
> 
> E.g. if checking NEED_RESCHED_LAZY somehow causes issues, it would be really nice
> for that to bisect to exactly that patch, not a patch that also switches to a
> completely different set of APIs.
> 
> And if someone is wants the fixes in a pre-6.18 kernel, they don't need to
> backport all of the KVM and entry code changes just to get the fix.

+1 on this.

Thanks,
Wei

> 
> As for the maintenance headache, see above.