Re: [GIT PULL] Networking deletions for 7.1

[Jakub Kicinski <kuba@kernel.org>]

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!

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

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