Policy regarding linux-next only changes

[Gary Guo]

Hi Mark,

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.

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.
8f598d86dc9c net: add "struct dst_entry" debugging
295e1a24166f net: update dev_put()/dev_hold() debugging
ca65ccfdc5b3 locking/lockdep: make lockdep_print_held_locks() always print if CONFIG_DEBUG_AID_FOR_SYZBOT=y
83d2b1cd5d27 lib/Kconfig.debug: add CONFIG_DEBUG_AID_FOR_SYZBOT option

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.

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.

Best,
Gary