On Thu, May 25, 2023 at 04:15:01PM +1000, Dave Chinner wrote:
> Google's syzbot does this now, so your syzkaller bot should also be
> able to do it....
>
> Please go and talk to the syzkaller authors to find out how they
> extract filesystem images from the reproducer, and any other
> information they've also been asked to provide for triage
> purposes.
Pengfei,
What is it that your syzkaller instance doing that Google's upstream
syzkaller instance is not doing? Google's syzkaller's team is been
very responsive at improving syzkaller's Web UI, including making it
easy to get artifacts from the syzkaller instance, requesting that
their bot to test a particular git tree or patch (since sometimes
reproducer doesn't easily reproduce on KVM, but easily reproduces in
their Google Cloud VM environment).
So if there is some unique feature which you've added to your syzbot
instances, maybe you can contribute that change upstream, so that
everyone can benefit? From an upstream developer's perspective, it
also means that I can very easily take a look at the currently active
syzbot reports for a particular subsystem --- for example:
https://syzkaller.appspot.com/upstream/s/ext4
... and I can see how often a particular syzbot issue reproduces, and
it makes it easier for me to prioritize which syzbot report I should
work on next. If there is a discussion on a particular report, I can
get a link to that discussion on lore.kernel.org; and once a patch has
been submitted, there is an indication on the dashboard that there is
a PATCH associated with that particular report.
For example, take a look at this report:
https://syzkaller.appspot.com/bug?extid=e44749b6ba4d0434cd47
... and look at the contents under the Discussion section; and then
open up the "Last patch testing requests" collapsible section.
These are some of the reasons why using Google's instance of syzkaller
is a huge value add --- and quite frankly, it means that I will
prioritize looking at syzkaller reports on the syzkaller.appspot.com
dashboard, where I can easily prioritize which reports are most useful
for me to look at next, over those that you and others might forward
from some company's private syzkaller instance. It's just far more
productive for me as an upstream maintainer.
Bottom line, having various companies run their own private instances
of syzkaller is much less useful for the upstream community. If Intel
feels that it's useful to run their own instance, maybe there's some
way you can work with Google syzkaller team so you don't have to do
that?
Are there some improvements to the syzkaller code base Intel would be
willing to contribute to the upstream syzkaller code base at
https://github.com/google/syzkaller? Or is there some other reason
why Intel is running its own syzkaller instance?
Cheers,
- Ted
