Is fgrep for whole reports possible?

[Tetsuo Handa]

Hello.

I'm trying debug printk() patches in linux-next kernels for examining
https://syzkaller.appspot.com/bug?extid=881d65229ca4f9ae8c84 , but
I can't find a new report from linux-next kernels for more than one week.

Since this bug likely happens within one or two days, I worry that syzbot
is categorizing output with my debug printk() patches as different bugs.
Can we check if "unregister_netdevice: waiting for DEV to become free"
messages are e.g. in "corrupted report" reports, without downloading
every report?

[Aleksandr Nogikh]

Hi Tetsuo,

Yes, apparently the bug hasn't been happening on linux-next lately
(I've just checked the instance's internal logs). It was last
registered on Nov 3.

Regarding the "corrupted report" bucket, we don't store more than what
is displayed on the web dashboard. Among those few reports, there are
no "unregister_netdevice" reports from the linux-next instance, so I'd
assume the bug has indeed not occurred since Nov 3.

--
Aleksandr

> --
> You received this message because you are subscribed to the Google Groups "syzkaller" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller+...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/syzkaller/21cb9696-5873-4f69-93af-31588eeca9f2%40I-love.SAKURA.ne.jp.

[Tetsuo Handa]

On 2025/11/12 20:54, Aleksandr Nogikh wrote:
> Hi Tetsuo,
>
> Yes, apparently the bug hasn't been happening on linux-next lately
> (I've just checked the instance's internal logs). It was last
> registered on Nov 3.
>
> Regarding the "corrupted report" bucket, we don't store more than what
> is displayed on the web dashboard. Among those few reports, there are
> no "unregister_netdevice" reports from the linux-next instance, so I'd
> assume the bug has indeed not occurred since Nov 3.
>

Thank you for checking. Hmm, I guess that the current situation is that
fuzzers can't examine network code that hits "unregister_netdevice" bucket
because some other bugs are crashing the kernel before examining network
code that hits "unregister_netdevice" bucket.

If my guess is correct, there are several choices.

(a) Make it possible to distinguish kernel configs for fuzz testings and
kernel configs for "#syz test" request, and add a syz command that allows
temporarily disabling problematic modules for some period (e.g. one week)
using the kernel configs for fuzz testings. => I think this choice is most
useful, for we can continue finding other bugs without waiting for specific
bugs to be fixed. When critical bug and minor bug are in linux-next.git ,
and minor bug is preventing critical bug from being discovered before
reaching to linux.git , linux-next.git won't help. We had experienced such
situation (since a bug report for linux-next.git was not immediately fixed,
some buggy changes failed to be tested by syzbot using linux-next.git ,
and the buggy changes reached to linux.git , resulted in flood of crashes)
in August 2022.

(b) Make fuzzers to use round-robin which code (e.g. vfs, filesystems, network,
drivers) to test. => This might to some degree help finding other bugs
without waiting for specific bugs to be fixed.

(c) Make it possible to specify reproducer to use for "#syz test" request.
=> Useful only when reproducer is already available, but easy to implement?

[Tetsuo Handa]

On 2025/11/12 22:40, Tetsuo Handa wrote:
> Thank you for checking. Hmm, I guess that the current situation is that
> fuzzers can't examine network code that hits "unregister_netdevice" bucket
> because some other bugs are crashing the kernel before examining network
> code that hits "unregister_netdevice" bucket.

I suspect that it is "ns: add active reference count" that made the kernel
crashed before hitting "unregister_netdevice" message.

>
> If my guess is correct, there are several choices.
>
> (a) Make it possible to distinguish kernel configs for fuzz testings and
> kernel configs for "#syz test" request, and add a syz command that allows
> temporarily disabling problematic modules for some period (e.g. one week)
> using the kernel configs for fuzz testings. => I think this choice is most
> useful, for we can continue finding other bugs without waiting for specific
> bugs to be fixed. When critical bug and minor bug are in linux-next.git ,
> and minor bug is preventing critical bug from being discovered before
> reaching to linux.git , linux-next.git won't help. We had experienced such
> situation (since a bug report for linux-next.git was not immediately fixed,
> some buggy changes failed to be tested by syzbot using linux-next.git ,
> and the buggy changes reached to linux.git , resulted in flood of crashes)
> in August 2022.

I thought that we need to distinguish kernel configs for fuzz testings and kernel
configs for "#syz test" request, for it is wrong to test patch for culprit module
using a kernel config with culprit module already disabled by someone else's request.

But I now think that we don't need to distinguish kernel configs for fuzz testings
and kernel configs for "#syz test" request if we can control kernel config options.
What we might want is that syzbot maintains a default kernel config, and developers
can apply delta against that default config for one week (valid for building kernel
for fuzz testings) or one-time (valid for building kernel for "#syz test" request).
That corresponds with the "kernel .config" part of #1611 ("dashboard/app: allow
specifying more parameters when testing patches").

The format for applying delta config for "#syz test" request would include
one or more optional #syz lines:

#syz add-kernel-config: CONFIG_FOO=y
#syz add-kernel-config: # CONFIG_BAR is not set.

Well, how to specify this for building kernel for fuzz testings which is not
associated with syzbo...@syzkaller.appspotmail.com address...

[Aleksandr Nogikh]

Technically, achieving this is already possible with #syz test - e.g.
if you also modify KConfig files in the supplied git diff to
force-enable or force-disable certain parameters. In the end,
syzkaller just applies the patch to a base tree, takes the .config
used when the bug was discovered, and runs `make olddefconfig` on top.
So if it becomes impossible to keep a particular option enabled, it
will just be disabled during the build process.

>
> (b) Make fuzzers to use round-robin which code (e.g. vfs, filesystems, network,
> drivers) to test. => This might to some degree help finding other bugs
> without waiting for specific bugs to be fixed.

In some sense, this is already the case: we have multiple syzkaller
instances on syzbot that use different architectures / virtualization
/ sanitizers and are built from different git trees. There are also
e.g. networking instances (that only use a networking-related subset
of syscalls), bpf instances, fs instances, etc.

>
> (c) Make it possible to specify reproducer to use for "#syz test" request.
> => Useful only when reproducer is already available, but easy to implement?
>

Yes, the implementation isn't difficult.

Though I am more curious about what the command would look like in
this case. Currently, we already have two formats (#syz test and #syz
test: repo branch), the latter being already a bit tricky to handle
because of line wrapping. If we add one more small parameter, it
likely won't complicate things much, but if we keep adding more of
them, we risk making it too hard to use and to explain.

[Tetsuo Handa]

On 2025/11/18 19:19, Aleksandr Nogikh wrote:
>> (c) Make it possible to specify reproducer to use for "#syz test" request.
>> => Useful only when reproducer is already available, but easy to implement?
>>
>
> Yes, the implementation isn't difficult.
>
> Though I am more curious about what the command would look like in
> this case. Currently, we already have two formats (#syz test and #syz
> test: repo branch), the latter being already a bit tricky to handle
> because of line wrapping. If we add one more small parameter, it
> likely won't complicate things much, but if we keep adding more of
> them, we risk making it too hard to use and to explain.

Multiple #syz commands in one mail. ;-)



By the way, what is the algorithm for selecting a reproducer when there are
multiple reproducers? Since the "#syz test" response mail does not include
information about which reproducer was used for testing, I worry that
"#syz test" did not use intended reproducer.

Currently we have several bugs in linux-next.git which make it difficult to
trigger the bug with my debug printk() patches applied.
Which repro will be used if I issue "#syz test" request mail against
https://syzkaller.appspot.com/bug?extid=881d65229ca4f9ae8c84 which has many
reproducers?

Prefer C repro over syz repro? Prefer latest repro over non-latest repro?
If so, C repro is not used when only syz repro is available as the latest one?
Making it possible to specify reproducer to use for "#syz test" request
will give us more control.

If syzbot can use the reproducer which I intend, I'd like to try my debug
printk() patches for "#syz test" request...