Re: Policy regarding linux-next only changes

[Miguel Ojeda]

On Sun, Jul 5, 2026 at 1:36 PM Tetsuo Handa
<penguin-kernel@xxxxxxxxxxxxxxxxxxx> wrote:
>
> My response on that proposal is
> https://groups.google.com/g/syzkaller/c/4Y3zvo_t_lI/m/jqRBCN5bBQAJ .

I am aware -- I read the thread before I replied. I was asking what
happened after the thread, i.e. what was the outcome, if some more
discussion took place elsewhere, etc.

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

Why? Just to avoid confusing myself: are you part of the team that
decides that allocation? Or are you saying that they ended up saying
it isn't possible to do so?

If these patches are so important, then the question is why those
resources cannot be committed, or why cannot linux-next testing be
reduced temporarily when there are such special runs going on.

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

I don't follow. If it were to be agreed that linux-next is the right
place for those tests, then those patches could simply be extra
branches that Mark could merge at the end -- no need to `git reset`
the "normal" subsystem branches.

In other words, just like you are doing with your branch, essentially.
But it is something that needs to be agreed upon first.

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

The kernel config option is orthogonal, in my view. That is, even if
the option were to be added, you would still need agreement to add
random patches for testing (including discussing when in the cycle is
best to do so, e.g. last time you added patches just before -rc7 which
is about the worst time to do so, and which did break rust-next).

Cheers,
Miguel