Re: Linking Patchwork with Sashiko?

[Mauro Carvalho Chehab <mchehab+huawei@kernel.org>]

On Wed, 15 Jul 2026 23:53:55 -0400
"Theodore Tso" <tytso@mit.edu> wrote:

> On Wed, Jul 15, 2026 at 11:00:54PM -0500, Nicolas Dufresne wrote:
> > In V4L2 m2m notably, there is a "job" in the background, which allow
> > to safely (at least this is the theory) chain up work, and
> > synchronize against pending work. But Sashiko (and other AI) seems
> > to not get it and state with confidence and long explanation that
> > the drivers are racy and should do X/Y/Z more on top (and never
> > blames the framework).  
> 
> Is there actually a race which is allowed by the framework?  Or is
> Sashiko's proposed race actually not possible?
> 
> Or is it a case where it actually *is* racy, but it's something we
> really don't care about?  I've seen this happen with KCSAN where
> technically it really *is* a data race, but it's actually not
> important --- so we just have to mark it with the data_race() macro[1].
> 
> [1] https://docs.kernel.org/dev-tools/lkmm/docs/access-marking.html
> 
> This sort of thing can happen any time we introduce a new tool,
> whether it's KCSAN or lockdep.  

Lockdep warnings are particularly tricky and hard to fix. We did
have false-positive lockdep warnings ("hallucinations") in the past
at subsystem level, which took years and a lot of work to find better
ways to fix them.

> It's not necesarily unique to AI
> reviews.  In both AI and non-AI tools, we can have developers who fix
> the problem in the wrong way, or where the fix actually makes things
> worse than the putative "bug".

Very true.

> > This is why I recommended not forwarding the reviews to the linux
> > media list just yet during the summit. Now, the tricky part will be
> > to find time to try and help narrow this down, I never checked the
> > implementation, but I suppose you can add more layers of prompts to
> > force into looking deeper ?  
> 
> Has a bug been filed with the Shashiko folks?  I can imagine any
> number of solutions, including adding comments in the source, or some
> kind of marker much like the data_race() macro to shut up KCSAN
> warnings, or __attribute__((unused)) to shut up gcc or Clang warnings.
> Yet another solution might be to add some kind of a AGENTS.md file in
> the explains why a particular construct is safe.  Personally, I
> consider it to be the less desirable solution, since having something
> inline in the sources is likely to get out of sync with future code
> changes, and having the annotation in the sources will hopefully be
> useful to humans, not just AI bots.
> 
> But the exact solution is going to be very specific exact warning and
> why the AI bot thinks there is a problem when it really isn't.

Agreed.

Just like any tool, LLM can produce very wrong or very good results
depending on how one uses it. I'm pretty much convinced that media
needs a custom set of prompts to avoid it to report false positives
and to make it point things that are more relevant to us.

> 
>     	       	      	       	 	 - Ted
> 
> P.S.  There was a recent thread[1] where using Clang's context
> analysis resulted in a false positive, and I think it's instructive to
> see how it was handled compared to false positives from Sashiko.  We
> had a discussion, and the result was two pull requests to LLVM to
> avoid the false positive.  There was no complaints about how the false
> positive somehow was demeaning to our humanity, or that we should be
> accomodate those people who want to ban the use of static analyzers.
> There is something about AI that seems to trigger a different sort of
> energy, for better or for worse.
> 
> [1] https://lore.kernel.org/r/20260712165610.366474-2-timday@thelustrecollective.com
> 



Thanks,
Mauro