Re: Policy regarding linux-next only changes

[Tetsuo Handa]

On 2026/07/02 20:49, Gary Guo wrote:
> Hi Mark,

Thank you for raising this problem.

> 
> While testing lockdep changes on linux-next, I found there is a commit
> ca65ccfdc5b3 ("locking/lockdep: make lockdep_print_held_locks() always print if
> CONFIG_DEBUG_AID_FOR_SYZBOT=y") applied to lockdep. Checking the history it
> looks like this commit has been in linux-next for quite a while (at least 2
> months); there were no emails on LKML about this commit at all.

Yes, these patches are for debugging difficult problems.

For example, ca65ccfdc5b3 has been a concern for almost 8 years without progress
because developers show little interest for this change:

  https://lkml.kernel.org/r/1535975097-19080-1-git-send-email-penguin-kernel@xxxxxxxxxxxxxxxxxxx
  https://lkml.kernel.org/r/7e0d2bbf-71c2-395c-9a42-d3d6d3ee4fa4@xxxxxxxxxxxxxxxxxxx

> 
> I asked Boqun and as a maintainer of the file he's not aware of such changes
> being made. This commit is being added to linux-next via the TOMOYO security
> module tree; checking the merge it appears that none of the changes pulled in
> via the TOMOYO tree is related to LSM at all:
> 
> e07d10ed0f23 lib/Kconfig.debug: enable CONFIG_PREEMPT_RT for syzbot kernels.

e07d10ed0f23 is for reproducing https://syzkaller.appspot.com/bug?extid=3f51ad7ac3ae57a6fdcc
in linux-next so that we can debug this problem in linux-next.git / test patches before
sending to linux.git .

> 8f598d86dc9c net: add "struct dst_entry" debugging
> 295e1a24166f net: update dev_put()/dev_hold() debugging

8f598d86dc9c and 295e1a24166f are for debugging https://syzkaller.appspot.com/bug?extid=e2af46126e0644cbebdd
in linux-next because netdev people are hardly responding to patches
(e.g. https://lkml.kernel.org/r/2bc332e0-b250-4679-a075-1c413ad843ce@xxxxxxxxxxxxxxxxxxx )
that will finally make these patches unnecessary.

> ca65ccfdc5b3 locking/lockdep: make lockdep_print_held_locks() always print if CONFIG_DEBUG_AID_FOR_SYZBOT=y

Explained at top.

> 83d2b1cd5d27 lib/Kconfig.debug: add CONFIG_DEBUG_AID_FOR_SYZBOT option

This is also a long-remaining concern without progress because developers show little
interest for this change:

    (2019-12-16 09:59) [PATCH] kconfig: Add kernel config option for fuzz testing.
    https://lkml.kernel.org/r/20191216095955.9886-1-penguin-kernel@xxxxxxxxxxxxxxxxxxx
    (2020-03-07 13:58) [PATCH v2] Add kernel config option for fuzz testing.
    https://lkml.kernel.org/r/20200307135822.3894-1-penguin-kernel@xxxxxxxxxxxxxxxxxxx
    (2020-03-08 16:13) Re: [PATCH v2] Add kernel config option for fuzz testing.
    https://lkml.kernel.org/r/CAHk-=wjCcCmQig8w8QEfyqyXACLzDc7b4TSW-KzAMzmS-QvJ+Q@xxxxxxxxxxxxxx
    (2020-04-13 06:33) [PATCH v3] Add kernel config option for tweaking kernel behavior.
    https://lkml.kernel.org/r/20200413063317.7164-1-penguin-kernel@xxxxxxxxxxxxxxxxxxx
    (2020-04-13 18:13) Re: [PATCH v3] Add kernel config option for tweaking kernel behavior.
    https://lkml.kernel.org/r/CAHk-=wgbMi2+VBN0SCEw9GeoiWgui034AOBwbt_dW9tdCa3Nig@xxxxxxxxxxxxxx
    (2020-04-16 00:47) Re: [PATCH v3] Add kernel config option for tweaking kernel behavior.
    https://lkml.kernel.org/r/5a72a7e8-f7fe-4560-0145-02d5570efa34@xxxxxxxxxxxxxxxxxxx

> 
> For obvious reasons I have concern about this practice; being a maintainer
> shouldn't mean that you're allowed to add random stuff to linux-next. This
> reminds me of another case last month
> https://lore.kernel.org/all/20260604210704.41751-1-ojeda@xxxxxxxxxx/ where the
> added stuff via TOMOYO tree breaks Rust build on linux-next. I think this
> practice is questionable and I would like a clarification on the policy of
> adding stuff that is not upstream material.

If maintainers were more responding to patches that help debugging difficult problems /
avoiding stupid behaviors, many of these patches would not have been staying as
"linux-next only" patches.

> 
> I recognize that there is a need to add commits that serve as testing and
> debugging purpose to linux-next, but I think any of these changes should be
> temporary in nature and have acknowledgement from maintainers of touched code.
> Perhaps these changes should also be in a separate topic branch which gets
> pulled from linux-next temporarily.

I'm happy if we can assign a git tree and a ML that are intended for temporary patches.
But please note that asking fuzzers to test a tree for hosting temporary patches is not
a choice. We need to test on massive instances to reproduce problems. linux.git is the
best tree for reproducing problems because of massive instances. But since we don't
want to pollute linux.git with temporary patches, I'm using linux-next.git as the place
for reproducing problems.

This practice is questionable, but just rejecting with "stop doing this practice" won't help.
I need interests / assistance from developers / maintainers for avoid doing this practice.