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: <20241202151231.GF773835@ziepe.ca>
Date: Mon, 2 Dec 2024 11:12:31 -0400
From: Jason Gunthorpe <jgg@...pe.ca>
To: Joerg Roedel <joro@...tes.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
	Dmitry Safonov <0x7f454c46@...il.com>, pr-tracker-bot@...nel.org,
	iommu@...ts.linux.dev, open list <linux-kernel@...r.kernel.org>,
	Will Deacon <will@...nel.org>
Subject: Re: [git pull] IOMMU Updates for Linux v6.13

On Tue, Nov 26, 2024 at 12:12:35PM +0100, Joerg Roedel wrote:
> On Mon, Nov 25, 2024 at 06:45:00PM -0800, Linus Torvalds wrote:
> > Those octopus merges may look cool, but you should never use an
> > octopus merge for anything that has any conflicts, because they are
> > hard to get right. Joerg clearly didn't get that one right.
> 
> Yeah, sorry, my bad. This time around there were unusually many
> conflicts between the topic branches, which also forced me to create
> two merge commits to put everything together. In this process I
> overlooked that the iommu_present() definition slipped through.

I know we talked about this before, but I think the topic branches and
octopus merge flow is troublesome. This cycle had lots of all-driver
work and it is a pain working like this.

We rarely seem to toss stuff out, it would be OK to just revert it, or
run a delayed two step promotion like Andrew does.

I especially don't like that this flow recreates the octopus merge
whenever the branches change so there is no stable tree for people to
follow, or to submit patches on top of the current state of the tree.

IMHO the more traditional flow of just merging patches/PR forward on a
single branch works better.

Jason

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ