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

Message-ID: <565b28fc-6561-4992-88fa-35808ba1fa07@sirena.org.uk>
Date: Mon, 22 Dec 2025 14:50:55 +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 Sun, Dec 21, 2025 at 11:10:11AM -0500, Sasha Levin wrote:

> I assigned categories to the various trees used by -next (see
> https://gist.github.com/sashalevin/163df4ae1163e0e22a97edc40e14b7f5) and built
> a simple wrapper script to generate per-category integration branches, letting
> LLMinus resolve conflicts whenever we hit one.

Those categories appear to be a bit randomly assigned FWIW.  I'm not
clear who would want the various intermediate merges either, I suppose
that having some of the trees pulled into multiple places might help
shake out some of the issues due to things getting sent to Linus in a
different order but OTOH it will increase the total number of merges
done and tested which is itself a cost.  We could also shake out
ordering issues by doing something like randomise the ordering.  I think
I'd want some demand or use case for doing more intermediate merges
rather than just doing a bunch of them for the sake of it.

This seems like a very separate experiment to your LLM merge thing.

> The resulting branches were pushed to
> https://git.kernel.org/pub/scm/linux/kernel/git/sashal/linux-next.git/refs/ .
> Each category has a %s-next branch, and a larger all-next branch which merges
> all of them together and is the equivalent of linux-next.

> Please let me know what you think!

It might be easier to tell what it's done if you ran this with the same
inputs as the last -next (it's on Christmas break at the minute),
there's quite large differences in the end result but most if not all of
that is that the input trees you're using are fresher than the last
-next.  Though I think even with the same base there'd be a bit of a
needle in a haystack thing finding interesting cases, probably it'd be
more useful to find and highlight specific cases where it does something
interesting.

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