Re: Linking Patchwork with Sashiko?

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

On Thu, Jul 16, 2026 at 10:07:03AM -0500, Jacopo Mondi wrote:
> I got fooled by a Sashiko reported issue on patch for a driver I
> maintain. I asked the developer to address it, he did so in a separate
> patch, people got involved, lost quite some time on it, it ended up
> being a false positive.

Thanks, I think I see why the Media subsystem has such a huge
difference in their experience of Sashiko.  With the media subsystem,
you have to support drivers and the driver maintainers don't
necessarily have as much deep experience with the core media
infrastructure / framework.  Hence, you didn't immediately realize
that something which was a false positive.  I'm going to guess that
you have three levels of expertise; (a) the patch authors, some of
whom might have very little experience with the kernel, since their
last project might have been developing the firmware for the card, (b)
the driver maintainers, who know that driver very well, but might not
have deep expertise the core media subsystems, and (c) the core media
infrastructure developers / maintainers, who *do* know what is and
isn't fair.

I think the other difference is that in the media subsystem, you can
rely on the userspace code being "nice" (so you don't need to worry
about certain races or cleanup bugs, because a well-behaved upper
layers of the stack would *never* abuse the kernel system call in that
way).  With file systems, we can *count* on syzbot abusing the system
call interface and filing bugs which they will report to management as
security bugs even though no sane userspace would ever do something
like that.  So we get things which we could call false positives all
the *time* from syzbot, and arguably, if this can be used to crash the
kernel, perhaps it's fair to call it a security issue.  After all, can
you guarantee that only well-behaved media frameworks will be calling
the media subsystem's kernel interfaces?

The combination of these two means that we've already hardened against
many of the cases where userspace does something "unusual", and we are
inured to ignoring many of the syzbot's "false positives" (After all,
if it requires root to trigger an oops, is it really a security issue?
It might be a quality of implementation issue, but if it's a
pre-existing issue, we've been getting complaints from syzbot for
years.)

And then because we don't have to deal with drivers, if we get someone
who is relatively inexperienced trying to fix a syzbot bug, the result
is almost always a complete disaster (especially since good luck
trying to get new contributors to run the regression tests) having the
Sashiko review point out the obvious bugs is a huge time server.
Furthermore, since we don't have the layer of driver maintainers, if
we get a false positive from Sashiko, we don't have trouble
recognizing them, and the main cost to us is telling the patch author
not to fix unrelated problems in a single commit --- and so to either
fix the Sashiko complaint in a separate commit, or to save it for a
later patch series.

This has also helped us because it sometimes gives a newer contributor
another opportunity to work on the subsystem, and we just have to make
sure to warn off a contributor that a particular issue proposed by
Sashiko mgiht be beyond that new contributor's experience.  But I've
seen a few cases where the new contributor has found Sashiko reviews
to be quite engaging.

Cheers,

						- Ted