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

[Andrew Morton <akpm@linux-foundation.org>]

On Fri, 9 Jan 2026 20:54:10 +0100 Borislav Petkov <bp@alien8.de> wrote:

> 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.

Yeah.  But it's quite rare, isn't it?  Collisions maybe a couple of
times a year?  (And this one wasn't MM!).  If ~6% of MM patches alter
x86 then that's 200-300/year, holy cow.  Given how cheap and quick it
is to resolve these things, should we be optimizing for these
rare collisions?

We did have one significant runtime problem from this about two years
ago.  For which I got thoroughly smacked around, while silently blaming
you guys ;)  You were cc'ed ~8 times over ~4 months!

> > 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.

Thanks.

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

Well what do I do and how long should we wait?

See the mm-new thing below.  This should help.

I think the typical profile here is a patchset that makes lots of MM
changes and some incidental x86 modifications, with dependency in both
directions.  I can be on the alert for significant alterations and mark
these for extra x86 consideration, although a single-line change can of
course break things.  I'd prefer to be able to get these patchsets into
mm's testing branches promptly, to maximize the overall contribution's
time-under-test.

Could I ask that when triaging these emails, you let me know promptly
if you'd prefer I not merge it, or to not upstream it without full x86
review, or whatever you want?  I can annotate or drop the patchset and
things will proceed smootly.

Incidentally, we recently added an "mm-new" branch to mm.git.  It's
withheld from linux-next, New material enters here and typically will
be moved into mm-unstable (and hence -next) after 2-3 days.  This is
mainly to try to avoid breaking linux-next.  This means if you see an
added-to-mm-new email, the patch won't be submitted to -next for a few
days.

IOW, that email is advance notification that the patch might appear in
linux-next a few days from now.  Hopefully that helps a bit?

(I'll actually be documenting all this Real Soon Now).

> 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.

I'd love me some acked-bys :)

I dunno, Boris.  Is it really worth the up-front and ongoing work for
something which happens so rarely and which Stephen handles so slickly?

> 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.

Yeah, that sucks.  I always pull his tree, do my test merge then do a
couple of build tests before sending the pull request.  I wish the guy
would publish his .configs so we can do `make linusconfig' to avoid the
grumpygrams.