Re: [GIT PULL] Networking deletions for 7.1

[Roman Gushchin <roman.gushchin@linux.dev>]

Jakub Kicinski <kuba@kernel.org> writes:

> On Fri, 24 Apr 2026 01:31:00 +0000 Roman Gushchin wrote:
>> 2c on Sashiko:
>
> Did I say Sashiko 3 times? ;)
> FTR - thanks a lot for the awesome work on that project!

You certainly did :)
Thank you and really appreciate your contributions to Sashiko!

>
>> 1) I'm working on an infrastructure to separate pre-existing issues from
>> new issues. My current thinking is to stop reporting these issues with
>> reviews of new patches and instead put them into some database and give
>> maintainers access to it. Sashiko will automatically deduplicate issues
>> and index them by the source file/subsystem. Hopefully it will mean that
>> maintainers will see only a limited number of issues in source files
>> they support. But I have yet to see how it works in practice.
>> 
>> But I'm somewhat concerned that this way many of these issues will
>> remain there forever and by reporting them with new material we actually
>> have better chances to get them fixes. Maybe it should be configurable
>> per-subsystem. I'm very open for ideas here.
>
> After a couple of hours of glasswing-inspired hacking today I wonder
> if we can close the loop on patch generation without blowing the budget.
> Or maybe a better question would be - how many of the issues are simple
> enough for the LLM to pop out a patch for, once it has all the context
> from the review.

My bet is <50% as of now, but I might be wildly off.

Even for human maintainers or very experienced kernel developers it's
common to have long discussions on what's the best approach, go through
multiple revisions etc. Current generation of LLMs is definitely worse
at code generation, so...

>> 2) Re false positives vs finding more bugs I had the same experience.
>> It's easy to tweak it to be more conservative or creative, but it comes
>> at a price. It seems like the real answer is simple a better model. We
>> saw a big improvement internally switching from Gemini Pro 3.0 to 3.1.
>
> Makes sense. What didn't really land for me until now is that at least
> for now different models are better at catching different types of bugs.
> Off the top of my head, Gemini does short work of misuses of DMA API
> without much context. Claude/codex/whatever the Meta one is called
> externally - none of them catch those.

Yeah, in a perfect world we would run code reviews using all best models
and combine results...