linux-kernel - Re: [RFC 0/5] LLMinus: LLM-Assisted Merge Conflict Resolution

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: <63de130e-6b92-4930-9b9d-093c2831c7b7@sirena.org.uk>
Date: Mon, 5 Jan 2026 18:30:19 +0000
From: Mark Brown <broonie@...nel.org>
To: Sasha Levin <sashal@...nel.org>
Cc: tools@...nel.org, linux-kernel@...r.kernel.org,
	torvalds@...ux-foundation.org, sfr@...b.auug.org.au
Subject: Re: [RFC 0/5] LLMinus: LLM-Assisted Merge Conflict Resolution

On Mon, Jan 05, 2026 at 01:00:20PM -0500, Sasha Levin wrote:
> On Tue, Dec 23, 2025 at 05:47:58PM +0000, Mark Brown wrote:

> > To be clear unless things are super prone to conflicts the big cost with
> > adding stuff to -next isn't generally doing the merges, it's build
> > testing the results.  To that end the main potential advantage I can see
> > in doing submerges would be if we could parallelise the build testing
> > portion of things.  That would need some consideration of the complexity
> > of the scripting, the build machines and the cogantive load involved,
> > and if we were doing that the considerations for constructing submerges
> > would be a bit different.  It has crossed my mind, but it'd be non
> > trivial to do and not intending to produce intermediate merges that are
> > useful to anyone else.

> The way I have it working is that I will only recreate a sub-tree if any of the
> -next trees that are part of it were rebased, otherwise I will just merge new
> changes on top of the existing tree.

> I will also do a build test only after I merged everything into the sub-tree.
> If we hit a build error, I will bisect between the last known good point and
> HEAD.

Yeah, there's already optimisations along those lines in there which
help a lot.

> Between the above, as well as tracking "known-broken" trees, the volume of
> build tests is not that scary.

Most of the time it's fine like you say, otherwise it'd be completely
unsustainable.  Some of the time between the number of trees that decide
to simultaneously make changes that trigger full allmodconfig rebuilds,
generate messy conflicts or whatever else things blow up in your face.
There's an interlock in the scripts that stops releases going out after
3am or something which I am pretty confident is in there due to bitter
experience.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)