Re: Policy regarding linux-next only changes

[Alexander Potapenko]

On Tue, Jul 21, 2026 at 1:49 PM Tetsuo Handa
<penguin-kernel@xxxxxxxxxxxxxxxxxxx> wrote:
>
> On 2026/07/21 18:38, Alexander Potapenko wrote:
> > Hi Tetsuo,
> >
> > You can send patches to syzbot@xxxxxxxxxxxxxxx.
> >
> > E.g. I ran
> >
> > $ git send-email  --suppress-cc=all --to=syzbot@xxxxxxxxxxxxxxx
> > patches/kcov-tetsuo-v7/0001-kcov-fix-data-corruption-and-race-conditions-on-PREE.patch
> >
> > to test your latest kcov patch and got the results here:
> > https://ci.syzbot.org/series/33930a89-bb2a-4c5a-b6c5-d45829d5c94c
> >
> > The fuzzing ran on 8 VMs for 3 hours, and there were no new reports.
> >
> > Please let us know what you think of this workflow.
>
> Unfortunately, 8 VMs for 3 hours would be too little to stop my linux-next only patches.
>
> syzbot took more than one month in linux-next until I was able to report
> https://lkml.kernel.org/r/73ed3aa5-f6e1-47b6-9e5d-428ac1f4cbf3@xxxxxxxxxxxxxxxxxxx .
> I could have reported within 24 hours if all VMs (I don't know how many VMs are assigned)
> for networking trees were tested with my linux-next only patch.

Currently, two syzbot instances point at linux-next:
ci-upstream-linux-next-kasan-gce-root (10 VMs) and
ci-upstream-rust-kasan-gce (4 VMs).
So, we would need 420 VM-days of fuzzing to find that bug. Adding the
20 machines currently fuzzing net and net-next (assuming those are the
ones you refer to) would have reduced the time to 12.5 days, but not
to 24 hours.
During that time, we would stop fuzzing the main net/net-next
repositories. Another problem is that switching instances between
different Git trees is not zero-cost; it requires manual
reconfiguration and introduces maintenance overhead.

Now imagine that requests to extensively fuzz with a certain debug
patch arrive every week.
How do we decide which of those deserve more attention from the fuzzer?
For how long should we keep those patches?
How do we ensure these patches do not conflict with each other?

>
> syzbot was not able to trigger
> "BUG: %s/%u is doing I/O request on loop%d in Lo_rundown state.\n" message
> using https://lkml.kernel.org/r/30ccdd3c-6353-4a0f-bdc7-230ec3bf4765@xxxxxxxxxxxxxxxxxxx
> in linux-next tree. syzbot could have triggered this message within 24 hours if all VMs
> for upstream trees were tested with my linux-next only patch.
>
> What I want is a workflow that can test with patches for many days and many VMs.

I am afraid the only way to achieve that is to ensure the patch
reaches upstream.

I could imagine a compromise: a community-maintained repository
containing a bunch of debug patches applied on top of linux-next.
But we won't be able to allocate too many resources to fuzzing that
repository (it would be just one of the many), so reproducing certain
bugs may still take weeks.