Re: Policy regarding linux-next only changes

[Tetsuo Handa]

On 2026/07/04 22:22, Theodore Tso wrote:
> On Sat, Jul 04, 2026 at 02:06:43PM -0500, Miguel Ojeda wrote:
>> Now, reading the Google Groups thread you link, it seems like your
>> *actual constraint* doesn't come from syzkaller, but rather that you
>> want to use the compute resources Google allocates for big trees like
>> linux-next.
> 
> Note that if you are trying to debug a specific syzbot bug, you don't
> need to send it to linux-next.  You can just reply to reproducer with
> 
> #syz test: git://repo/address.git branch-or-commit-hash

For bugs which have reliable reproducers, "#syz test:" will work.
My debug printk() patches are for bugs which don't have reproducers (or
reproducer is too unreliable to reproduce). I need large compute resources
for debugging such bugs.

On 2026/07/04 21:06, Miguel Ojeda wrote:
> I understand it may be nice to use such resources, but the solution is
> to talk to both sides, as you do in that thread. From what I see, they
> even offered to add a mailing list for those patches:
> 
>   "Aleksandr says we can create a special mailing list to test draft
>   patches, so the series sent to that list is fuzzed for some time,
>   similarly to how upstream patch testing works now.
>   Do you think that would help you to debug these issues? "
> 
> So what happened with that? It seems there was a way forward there,
> no? (Cc'ing Alexander from that thread)

My response on that proposal is
https://groups.google.com/g/syzkaller/c/4Y3zvo_t_lI/m/jqRBCN5bBQAJ .
In short, if trees with custom patches were tested with as much resources
and many patterns/testcases as trees without custom patches, I won't need
to carry custom patches in linux-next. But I think that we can't afford
allocating so much resources for trees with custom patches.

I have carried custom patches in linux-next and it resulted in 10 patches
for https://syzkaller.appspot.com/bug?extid=881d65229ca4f9ae8c84 where
"#syz test:" did not work. Since remaining bugs are no longer easily
reproducible in linux-next, I want to carry custom patches in the networking
trees. But in general, git trees are not supposed to make "git reset --hard"
changes.

Therefore, I am using my git tree as if "quilt" for making "git reset --hard"
changes in linux-next tree. If a kernel config option which is used for fuzz
testing were available in upstream, it will make easier to manage custom patches
for temporary debugging and pinpoint-blocking stupid operations (like SysRq-b).