Message-ID: <20260111110231.GAaWODR6gOvIp6KzD6@fat_crate.local>
Date: Sun, 11 Jan 2026 12:02:31 +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 02:00:26PM -0800, Andrew Morton wrote:
> 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?

Probably not but if we're optimizing anyway, might as well take care of that
too. :)

But I agree - such collisions are very seldom. Luckily.
 
> 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!

Probably it was somewhere in the mail firehose... :-\

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

That would be the timeframe we all agree upon...

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

Yap, and if you take a look at the patches you mentioned upthread - I did look
at the x86 bits in the clear_page set so that that is reviewed and can go
together through your tree.

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

The problem is, most of the time there's so much email so that all of us are
drowning in it to even be able to react. Remember the last time where Peter
and I were asking you to drop a patch from your queue? I think you didn't even
react because of -ETOOMUCHMAIL.

So to make things simpler, maybe we could say:

- patches which touch x86 only and there are no mm dependencies, go only
  through us. Including kexec. I think you'd like this because it'll take some
  of your load off

- mixed sets would probably need a week or so reaction time from us. If no
  reaction, I guess you take 'em. And we'll try to send acks/reviews. This
  will become even easier when we get the AI to review. Apparently, trying to
  get people to review more hasn't had any palpable success over the years so
  might as well let AI replace them here. :-P

How does that sound?

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

Ack, good to know.

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

Right.

> I'd love me some acked-bys :)

Yeah, we'll try to be more verbose...

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

Nah, if anything and as said, we'd address this as a by-product of other
workflow optimizations.

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

So he builds an allmodconfig, AFAIK, of every pull request, with both
compilers.

That's what I do too with our pull requests come merge window: I merge them
locally and build allmodconfigs of each one. This has caught pretty much every
issue, AFAIR.

Thx.

-- 
Regards/Gruss,
    Boris.

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

Powered by blists - more mailing lists