Re: Policy regarding linux-next only changes

[Boqun Feng]

[Cc Locking & Greg]

On Thu, Jul 02, 2026 at 09:49:43PM +0900, Tetsuo Handa wrote:
> 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
> 

This email was from 6 years ago, if that's the latest version, I'm not
so sure you could say "developers show little interest for this change".
Maybe you could provide more context about this that I missed? Also Greg
left a comment there, you neither replied nor send a version to resolve
it. Again I'm not sure if that could count as "developers show little
interest for this change".

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

I don't understand why it's not an option, couldn't you just ask syzbot
to apply the patches only for linux-next, or merge a tree but only for
linux-next? The point is not just syzbot consumes linux-next, everyone
does. Although I trust your good intents, but temporarily patches
(especially when they are silently merged into linux-next) can undermine
what linux-next is supposed to be.

By "silently" I mean I didn't see you gave a heads-up about doing this
either, e.g. an email saying "hey I'm including these into the
linux-next". Maybe I'm missing something here?

Regards,
Boqun

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