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] [day] [month] [year] [list]

Message-Id: <20260112123126.83e94ae2fe17829e32b0ea75@linux-foundation.org>
Date: Mon, 12 Jan 2026 12:31:26 -0800
From: Andrew Morton <akpm@...ux-foundation.org>
To: Borislav Petkov <bp@...en8.de>
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 Sun, 11 Jan 2026 12:02:31 +0100 Borislav Petkov <bp@...en8.de> wrote:

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

oops.  When triaging Subjects, something which is clearly x86 gets less
love.

> 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

Sure.

> - mixed sets would probably need a week or so reaction time from us.

No probs.

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

I'm optimistic.  Did you see Mathieu's review of a Gemini review? 
https://lkml.kernel.org/r/6fbb17fe-f2b1-4233-9834-5a5020cd87b3@efficios.com

> 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

Yeah.  I've been paying a lot of attention to the review economy
lately, I'm hopeful we can do some things to help level the playing
field, take load off those few who do so much of it.  Early days.

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

OK.  arm allnoconfig is fun.  It's super fast.  It's nommu and finds
things...