Re: Linking Patchwork with Sashiko?

["Theodore Tso" <tytso@mit.edu>]

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

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

    	       	      	       	 	 - 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