linux-kernel - Re: linux-next: build failure after merge of the tip tree

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: <20260109195410.GGaWFc4o-TL_jhOTxF@fat_crate.local>
Date: Fri, 9 Jan 2026 20:54:10 +0100
From: Borislav Petkov <bp@...en8.de>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Stephen Rothwell <sfr@...b.auug.org.au>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...nel.org>, "H. Peter Anvin" <hpa@...or.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linux Next Mailing List <linux-next@...r.kernel.org>
Subject: Re: linux-next: build failure after merge of the tip tree

On Fri, Jan 09, 2026 at 11:39:21AM -0800, Andrew Morton wrote:
> I'm not particularly concerned about these integration and build issues. 
> Shit happens, that's what -next is for and we fix things quickly.

Except that I don't like mails from sfr saying, "oh well, a patch in tip is
breaking something but it must be coming from a different tree because tip
alone builds fine."

So I go and do some crazy bisection dances on a big fat machine.

linux-next is there, AFAIU, to avoid exactly that - cross-tree conflicts,
amongst other things.

> My main concern is to avoid placing too many developers on the critical
> path for MM development.
> 
> I mean, it's a really common thing.  Because we all love statistics,
> mm.git MM development branches presently hold 262 patches, 16 of which
> alter arch/86!

Yah, I know. I do look at all your emails when you pick up stuff into your
trees and I mark them accordingly.

However, I don't like it when you pick up stuff too quickly, without any
review by us.

And it's not like there are no solutions for cross-tree patchsets - immutable
branches, acked-bys etc so that the whole set goes through one tree, and so
on.

Don't get me wrong - I see your point but what is missing, IMO, is better sync
between the trees. I can work with almost any setup and tree configuration
- but I'd like to be in the know and be aware of the situation and what goes
where.

And when Linus says that something doesn't build during the merge window, I'd
like to be prepared instead of both trees scrambling last-minute to figure out
why.

I hope that makes sense.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette