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: <aVv8NMl4aQwRcJ-E@laps>
Date: Mon, 5 Jan 2026 13:00:20 -0500
From: Sasha Levin <sashal@...nel.org>
To: Mark Brown <broonie@...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 Tue, Dec 23, 2025 at 05:47:58PM +0000, Mark Brown wrote:
>On Tue, Dec 23, 2025 at 07:36:18AM -0500, Sasha Levin wrote:
>> On Mon, Dec 22, 2025 at 02:50:55PM +0000, Mark Brown wrote:
>> > On Sun, Dec 21, 2025 at 11:10:11AM -0500, Sasha Levin wrote:
>
>> > 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.
>
>> My thinking around it was to enable faster per-subsystem tests than what we
>> currently do. For example, we can quickly build mm-next and run mm focused
>> tests on it.
>
>If we start putting everything into intermediate merges then inevitably
>some of those merges are going to be later in the process and will get
>generated later in the process, meaning they're nearer to the production
>of the full -next.  I'm also not clear that we have enough trees that
>would update multiple times a day.

I've left the script running over the holiday break, and the rate of changes is
very surprisingly high (specially given it was a holiday in most of the
world!).

>> Since creating these per-subsystem trees is fairly cheap and can happen even
>> few times a day, we can help identify issues way earlier during the process.
>
>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.

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

-- 
Thanks,
Sasha