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] [thread-next>] [day] [month] [year] [list]
Message-ID: <78b0297c-4622-4b75-bcae-45c144c92c45@sirena.org.uk>
Date: Tue, 21 Oct 2025 15:00:30 +0100
From: Mark Brown <broonie@...nel.org>
To: Marc Zyngier <maz@...nel.org>
Cc: Sascha Bischoff <Sascha.Bischoff@....com>,
	"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>,
	"kvmarm@...ts.linux.dev" <kvmarm@...ts.linux.dev>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>, nd <nd@....com>,
	"oliver.upton@...ux.dev" <oliver.upton@...ux.dev>,
	Joey Gouly <Joey.Gouly@....com>,
	Suzuki Poulose <Suzuki.Poulose@....com>,
	"yuzenghui@...wei.com" <yuzenghui@...wei.com>,
	Paolo Bonzini <pbonzini@...hat.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Aishwarya.TCV@....com
Subject: Re: [PATCH] KVM: arm64: gic-v3: Only set ICH_HCR traps for v2-on-v3
 or v3 guests

On Tue, Oct 21, 2025 at 08:50:22AM +0100, Marc Zyngier wrote:
> Mark Brown <broonie@...nel.org> wrote:

> > It didn't appear in -next since the arm64 KVM fixes tree is not directly
> > in -next and it was only pulled into Paolo's tree on Saturday, a few
> > hours before Paolo sent his pull request to Linus, so there was no
> > opportunity for it to be picked up.  As I've previously suggested it
> > does seem like it would be a good idea to include the fixes branches for
> > the KVM arch trees in -next (s390 is there, but I don't see the others),

> As I explained to you more than once, the answer is still no. We keep
> the two branches separate for good reasons -- for a start, they are
> manager by different people.

You do keep saying that but I am still unable to understand your
reasoning here.  Having two separate branches is very standard, it is
the normal pattern for fixes branches in -next and does not generally
present any problems that I am aware of.  A bit more than a third of the
branches merged by -next are fixes branches.  As I said in my earlier
reply to Sean it can be an advantage to have the fixes in -next
separately since this allows the fixes to go into pending-fixes, helping
spot unintended dependencies on work that's targeting the merge window
and ensure coverage continues even when there is breakage in development
code.

As I understand it the management of the KVM arm64 tree is very similar
to that for the arm64 architecture tree.  That has the separate feature and
fixes branches in -next, each managed by different people and both of
which are in -next.  So far as I am aware this hasn't been causing Will
and Catalin any problems, I don't know what would be different about the
KVM arm64 tree here.

The only thing I can think of is that you are objecting to the idea of
having the KVM arm64 tree merge it's fixes branch into it's development
branch.  That is not what I am suggesting, I am suggesting putting the
fixes branch itself directly into -next to be merged by Stephen.  I am
not proposing any change to the content of the KVM arm64 branches.

> If you want to manage a -fixes tree, go for it. If you want to take
> the -fixes branch in your CI, I have no objection.  Do I support this?
> Absolutely not.

There is no need for anyone to create a -fixes tree since we already
have pending-fixes, created as part of building -next.  The merge for
-next pulls in all the fixes branches first, publishes that as
next/pending-fixes, and then merges the new feature branches on top of
that to publish as next/master.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ