Re: Linking Patchwork with Sashiko?

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

On Fri, 17 Jul 2026 08:20:48 -0400
"Theodore Tso" <tytso@mit.edu> wrote:

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

While there are still a certain amount of (a) and (b), a large amount
of media patches comes from experienced media driver developers with
a reasonable expertise at the core, as several vendors opt to hire
open source development companies.

For (a), current Sashiko reports could look scary, as false positives
might end causing confusion. We tried to reach a consensus with regards
to c/c the author. About half of the comments from people who 
participated at the last media summit think it was OK to c/c the author
at Sashiko reviews provided we add a disclaimer notice at the top of the
e-mail body; the other half thinks otherwise. Yet, there was a consensus
to enable Sashiko for a couple of Kernel releases to see how it goes.

So, we opted to start without c/c the author and placing reviews on a
separate opt-in ML, while also adding them to our patchwork instance
as well.

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

Yes, this is true. Also, V4L2 and dvb core are responsible to receive
system calls, passing them to drivers only after checking for abuses.

So, most of the issues there are things like use-after-free, error
handling logic, and lack of resource de-allocation (which is only an
issue, in practice, for usb drivers).

There are still a fair amount of such bugs, which is where Sashiko
and static analyzers can help more.

That's one of the reasons why I do think media needs its own custom
prompts.

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

Syzbot issues are usually related to V4L2 core. We don't get many such
reports, probably because v4l2 core doesn't have too much changes those
days.

-- 
Thanks,
Mauro