Policy regarding linux-next only changes

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@kernel.org/ 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

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@I-love.SAKURA.ne.jp
  https://lkml.kernel.org/r/7e0d2bbf-71c2-395c-9a42-d3d6d3ee4fa4@i-love.sakura.ne.jp

> 
> 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@I-love.SAKURA.ne.jp )
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@I-love.SAKURA.ne.jp
    (2020-03-07 13:58) [PATCH v2] Add kernel config option for fuzz testing.
    https://lkml.kernel.org/r/20200307135822.3894-1-penguin-kernel@I-love.SAKURA.ne.jp
    (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@mail.gmail.com
    (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@I-love.SAKURA.ne.jp
    (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@mail.gmail.com
    (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@i-love.sakura.ne.jp

> 
> 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@kernel.org/ 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.

Re: Policy regarding linux-next only changes

[Miguel Ojeda]

On Thu, Jul 2, 2026 at 2:49 PM Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
>
> 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.

Did you get an agreement from others (e.g. from Mark himself or those
maintainers), or not?

As I mentioned to you last time in the thread that Gary linked, the
standard linux-next rules do not allow for this. Of course, rules can
bent (or changed) when there is a need, but it sounds to me like you
are surprising others, even maintainers of related code, by
unilaterally adding whatever patches you deem important, without prior
agreement.

If you think something is really important, and there was disagreement
(I don't know the context), then you should try to work with others to
make them see why it is important, e.g. bring it to the Ksummit list,
to LPC, escalate it, etc. But doing things unilaterally breaks the
trust, especially when it is not the first time.

And why do you say fuzzers cannot test whatever tree you need? Can you
please elaborate what the actual problem is? Maybe it can be solved in
another way?

(Cc'ing Greg here too since I see from your threads that you discussed
with him patches for fuzzing in the past several times.)

Cheers,
Miguel

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@I-love.SAKURA.ne.jp
>   https://lkml.kernel.org/r/7e0d2bbf-71c2-395c-9a42-d3d6d3ee4fa4@i-love.sakura.ne.jp
> 

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@I-love.SAKURA.ne.jp )
> 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@I-love.SAKURA.ne.jp
>     (2020-03-07 13:58) [PATCH v2] Add kernel config option for fuzz testing.
>     https://lkml.kernel.org/r/20200307135822.3894-1-penguin-kernel@I-love.SAKURA.ne.jp
>     (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@mail.gmail.com
>     (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@I-love.SAKURA.ne.jp
>     (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@mail.gmail.com
>     (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@i-love.sakura.ne.jp
> 
> > 
> > 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@kernel.org/ 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.
> 

Re: Policy regarding linux-next only changes

[Tetsuo Handa]

On 2026/07/02 23:11, Boqun Feng wrote:
>>> 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@I-love.SAKURA.ne.jp
>>   https://lkml.kernel.org/r/7e0d2bbf-71c2-395c-9a42-d3d6d3ee4fa4@i-love.sakura.ne.jp
>>
> 
> 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?

I don't remember whether some discussions are done somewhere else. But judging from
the fact that code remains unchanged, nobody else has attempted or succeeded to
make this change.

Peter Zijlstra has commented at
https://lkml.kernel.org/r/20200313083107.GV12561@hirez.programming.kicks-ass.net
that disabling

	if (p->state == TASK_RUNNING && p != current)
		return;

check increases UAF potential, and suggested a kernel command line parameter for
whether to disable this check.

At the same time, Peter has thought that the risk of UAF is quite low.
As far as I know, syzbot did not hit UAF caused by disabling this check
(commit ca65ccfdc5b3 ("locking/lockdep: make lockdep_print_held_locks()
always print if CONFIG_DEBUG_AID_FOR_SYZBOT=y"). So, I guess that we can add
a switch (I prefer a kernel config option over a kernel command line parameter)
for this change.

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

Linus does not like use of kernel config options, but I don't like use of kernel
command line parameters
( https://lkml.kernel.org/r/3ee9c586-002b-f504-9e3b-5afa8929209b@i-love.sakura.ne.jp ).

(1) Adding one switch for one behavior (either a kernel config option or a kernel command
    line parameter) is an endless game of maintaining list of switches. Unless someone finds
    that a dedicated switch is useful for specific case, number of switches should remain
    minimized.

(2) Boot-time switches (i.e. kernel command line parameters) which are visible to
    userspace (e.g. /proc/cmdline, /proc/1/cmdline, sysfs and maybe more) are more
    difficult to maintain (i.e. follow the "never break the userspace" rule) than
    compile-time switches (i.e. kernel config options) because the kernel implementation
    might change in a way that makes boot-time switches unnecessary (e.g. switches that
    are intended for debugging will become unnecessary after some problem is fixed).

(3) Run-time switch increases size of executable files and cost for runtime evaluation.
    Also, assembly dump will include pointless code which is never executed due to run-time
    switch. Excluding should-not-be-executed-code from the beginning minimizes size and cost.

(4) Compile-time switch is easier to prove configurations than scanning very very long kernel
    command line which is likely already excluded from the console log of a crash report.

As a whole, I prefer compile-time and a global switch. If someone finds that run-time and/or
individual switch is more useful, we can change to run-time and/or individual switch as needed.
But no more response from Greg or Linus...



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

Basic constraint is
https://github.com/google/syzkaller/blob/master/docs/syzbot.md#no-custom-patches .

I don't know whether
https://groups.google.com/g/syzkaller/c/4Y3zvo_t_lI/m/z-4-79ZHBQAJ
could loosen this constraint to some degree.

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

I know that syzbot is not the only consumer of linux-next. Therefore, I try to minimize
users affected (e.g. guard changes by CONFIG_DEBUG_AID_FOR_SYZBOT=y or CONFIG_KCOV=y )
when making changes.

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

I'm fine with announcing to ML that I am about to make debug/temporary changes.
But we might want a prefix for debug/temporary patches that are not intended for upstream?
Also, we might want a kernel config option (e.g. CONFIG_DEBUG_AID_FOR_SYZBOT) for
minimizing users affected?

Re: Policy regarding linux-next only changes

[Miguel Ojeda]

On Sat, Jul 4, 2026 at 12:15 PM Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
>
> Basic constraint is
> https://github.com/google/syzkaller/blob/master/docs/syzbot.md#no-custom-patches .

No, that section talks about two different things: patches that are
fixes as well as temporary debugging patches.

For the former, it just says you should talk to maintainers to land
the fix. That is: you need agreement from maintainers, which is what
we have been saying.

For the latter, it simply says that sometimes debugging patches have
been added in the past to linux-next. It doesn't say it was done
unilaterally. (And even if it did, it is just a third-party document).

Critically, the section also explicitly ends with:

  "One can also always run syzkaller locally on any kernel for better
stress testing
   of a particular subsystem and/or patch."

...which sounds logical to me and is precisely what I was asking. So
to me it seems you don't actually need to put it in linux-next.

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.

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)

Cheers,
Miguel

Re: Policy regarding linux-next only changes

[Theodore Tso]

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

So I think we need to distinguish between two cases.  One is where you
are trying to address specific syzkaller reproducer.  The other is
where you want to do a full set of fuzzing on a draft series.  I'd
argue that though, that this is something you want to do when the
patch is almost ready to land upstream --- and at that point, putting
in linux-next makes perfect sense.

I'm not really see the case where it's not quite ready to land
upstream (and so you want the full set of testing, not just with
syzbot, with other people testing linux-next), but you still want to
get the full set syzkaller testing.

Do people think this is really such a common scenario?

						- Ted

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

Re: Policy regarding linux-next only changes

[Miguel Ojeda]

On Sun, Jul 5, 2026 at 1:36 PM Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> 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

Re: Policy regarding linux-next only changes

[Miguel Ojeda]

On Sun, Jul 5, 2026 at 2:02 PM Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
>
> is about the worst time to do so, and which did break rust-next).

s/rust-next/the `rustdoc` and Clippy clean builds in linux-next/

Cheers,
Miguel

Re: Policy regarding linux-next only changes

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1218 bytes --]

On Sun, Jul 05, 2026 at 02:02:11PM +0200, Miguel Ojeda wrote:

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

Yes, this is a good approach. Branches can be added or removed
pretty easily so there's no problem on my end - I add temporary branches
relatively often, there's currently one for Uwe's device ID reworks for
example.  Sometimes trees are managed in a way that makes it easy for
the tree to do this locally too (eg, arm-soc merges all their topic
branches themselves) so the maintainer might be happy to add things to
their tree but if not then a temporary branch is a good approach.

If for some reason there's some difficulty in working with the relevant
maintainers (eg, they're just not responding to mail at all) the process
of asking for a branch to be added to -next is also a good way of making
people aware that there's some issues and having some degree of
coordination.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Policy regarding linux-next only changes

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1860 bytes --]

On Sat, Jul 04, 2026 at 02:06:43PM +0200, Miguel Ojeda wrote:
> On Sat, Jul 4, 2026 at 12:15 PM Tetsuo Handa

> For the latter, it simply says that sometimes debugging patches have
> been added in the past to linux-next. It doesn't say it was done
> unilaterally. (And even if it did, it is just a third-party document).

...

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

Right, this seems to be something where people need to talk more.  It
does seem like there's real communication problems that need to be
addressed, it looks like some progress is being made thanks to this
thread.

Just dropping patches into -next that people are unaware of is going to
cause issues sooner or later.  Either there'll be some direct collision
with other work or (probably worse) they'll cause someone to think that
something is working better than it actually is since people testing
-next are testing with some extra stuff that the maintainers weren't
aware of.  It might be that the most sensible thing is to have some
extra patches in there for a period, it's an expected part of the flow
that things might get backed out after all, but we want to avoid
surprises.

> > I'm fine with announcing to ML that I am about to make debug/temporary changes.
> > But we might want a prefix for debug/temporary patches that are not intended for upstream?
> > Also, we might want a kernel config option (e.g. CONFIG_DEBUG_AID_FOR_SYZBOT) for
> > minimizing users affected?

TBH I think a prefix is probably not needed since there should be a bit
more communciation about what's going on than just posting the patch -
some discussion about how to debug whatever's going on for example.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Policy regarding linux-next only changes

[Tetsuo Handa]

On 2026/07/05 21:06, Mark Brown wrote:
> On Sat, Jul 04, 2026 at 02:06:43PM +0200, Miguel Ojeda wrote:
>> On Sat, Jul 4, 2026 at 12:15窶ｯPM Tetsuo Handa
> 
>> For the latter, it simply says that sometimes debugging patches have
>> been added in the past to linux-next. It doesn't say it was done
>> unilaterally. (And even if it did, it is just a third-party document).
> 
> ...
> 
>> 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:
> 
> Right, this seems to be something where people need to talk more.  It
> does seem like there's real communication problems that need to be
> addressed, it looks like some progress is being made thanks to this
> thread.

Yes, thanks to this thread. There is real communication problems.
Developers / maintainers are too busy to continue threads on my patches.
Let's see several examples.

Example 1: (not a problem with linux-next only patch, but a communication problem)

  Linus's "None of this makes any sense." comment at
  https://lkml.kernel.org/r/CAHk-=wjmFiptPgaPx9vY3RG=rqO452UmOAPb1y_f9GQBtuJVjg@mail.gmail.com
  made Mikulas to say "I don't know what else to do." at
  https://lkml.kernel.org/r/290bd5eb-9638-53ce-3c71-23b996d6ba54@redhat.com , causing
  https://lkml.kernel.org/r/329e1951-0704-4d90-aeeb-ffc7123f4262@I-love.SAKURA.ne.jp and
  https://lkml.kernel.org/r/9a05e50c-75c1-4452-b40f-f5a8b487f3ed@I-love.SAKURA.ne.jp to stall.
  We need clarification from Linus or response from Mikulas.

Example 2: (a problem with moving from linux-next only patch to networking patch, but a communication problem)

  I responded to Jakub's "Have you see netdev_hold() / netdev_put() ?" comment at
  https://lkml.kernel.org/r/20260325192214.133ffaaf@kernel.org but got no response.
  I need clarification or response from Jakub. If some core maintainer asks network
  people "Let's update all existing dev_put()/dev_hold() users to use netdev_put()/
  netdev_hold()", some progress would be made. No progress as long as no response.

Example 3: (a problem with linux-next only patch, but a communication problem)

  I responded to Al's "Not a peep in the logs, breakage still there" comment at
  https://lkml.kernel.org/r/ebceac56-6a65-4918-b47c-1fb87aa66989@I-love.SAKURA.ne.jp
  but got no response. Therefore, I sent an updated version
  https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit?id=3ae78a69d3a9a4ad1d3b267324bd742654f40965
  to linux-next, and I am currently waiting for syzbot to reproduce this problem.

Re: Policy regarding linux-next only changes

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 2757 bytes --]

On Sun, Jul 05, 2026 at 11:16:02PM +0900, Tetsuo Handa wrote:
> On 2026/07/05 21:06, Mark Brown wrote:
> > On Sat, Jul 04, 2026 at 02:06:43PM +0200, Miguel Ojeda wrote:

> Example 1: (not a problem with linux-next only patch, but a communication problem)

>   Linus's "None of this makes any sense." comment at
>   https://lkml.kernel.org/r/CAHk-=wjmFiptPgaPx9vY3RG=rqO452UmOAPb1y_f9GQBtuJVjg@mail.gmail.com
>   made Mikulas to say "I don't know what else to do." at
>   https://lkml.kernel.org/r/290bd5eb-9638-53ce-3c71-23b996d6ba54@redhat.com , causing
>   https://lkml.kernel.org/r/329e1951-0704-4d90-aeeb-ffc7123f4262@I-love.SAKURA.ne.jp and
>   https://lkml.kernel.org/r/9a05e50c-75c1-4452-b40f-f5a8b487f3ed@I-love.SAKURA.ne.jp to stall.
>   We need clarification from Linus or response from Mikulas.

That's less than a week old, and isn't it part of a bigger discussion
that was going on between the filesystem people and the fuzzer people
about how much to trust the data on disks?

> Example 2: (a problem with moving from linux-next only patch to networking patch, but a communication problem)

>   I responded to Jakub's "Have you see netdev_hold() / netdev_put() ?" comment at
>   https://lkml.kernel.org/r/20260325192214.133ffaaf@kernel.org but got no response.
>   I need clarification or response from Jakub. If some core maintainer asks network
>   people "Let's update all existing dev_put()/dev_hold() users to use netdev_put()/
>   netdev_hold()", some progress would be made. No progress as long as no response.

That one seems like you need to follow up, it's been a quite a while.
Probably mentioning the issues with netdev_hold()/put() (you said there
were some, but I can't tell from the thread what they are) and the
patches you want in one mail so things are more directly actionable.

> Example 3: (a problem with linux-next only patch, but a communication problem)

>   I responded to Al's "Not a peep in the logs, breakage still there" comment at
>   https://lkml.kernel.org/r/ebceac56-6a65-4918-b47c-1fb87aa66989@I-love.SAKURA.ne.jp
>   but got no response. Therefore, I sent an updated version
>   https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit?id=3ae78a69d3a9a4ad1d3b267324bd742654f40965
>   to linux-next, and I am currently waiting for syzbot to reproduce this problem.

Again, that one seems fairly new (a bit staler than the first one).  We
did have the merge window though, some people drop everything when that
passes.

It does look like you're seeing some stuff getting dropped on the floor
here but TBH it doesn't look super unusual.  There is a bit of an issue
in our processes with things getting stuck in a quite submitter
unfriendly way so you do often need to keep pushing on things.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[PATCH] lockdep: Enable the printing of held locks of running non-current tasks (was: Policy regarding linux-next only changes)

[Ingo Molnar]

* Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> wrote:

> On 2026/07/02 23:11, Boqun Feng wrote:
> >>> 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.

Yeah, so while it's still true that printing out their held locks
array is racy, it's not as bad as it seems.

There's 16 internal callers to lockdep_print_held_locks():

 - 14 callers call it with the current task, which should be
   safe out of box.

 - 1 caller, debug_show_all_locks(), calls it with RCU held,
   which should guarantee that 'p' cannot go away under us.

 - 1 caller, debug_show_held_locks(), exposes the internal API
   with the constraint that it should only be called by drivers
   or platform code if the task isn't actively running - we can
   assume that if it nevertheless does, it will be Their Problem™.

As for held locks being changed from under debug_show_held_locks(),
while the task cannot go away, so the held-locks array itself is
safe (although potentially non-stable), AFAICS the worst-case race
can be garbage printed out by print_lock(), not any actual crashes.

In particular:

        unsigned int class_idx = hlock->class_idx;

may be stale (belong to a lock that already got released on another
CPU), but it should still be a valid class index bound by
MAX_LOCKDEP_KEYS, and thus the lock_classes_in_use bitmap use
should be safe.

The other two accesses are ::acquire_ip and ::instance:

       printk(KERN_CONT "%px", hlock->instance);
       print_lock_name(hlock, lock);
       printk(KERN_CONT ", at: %pS\n", (void *)hlock->acquire_ip);

But both are printed out as pointers, so no risk of dereference
of a dangling pointer. We may print a garbage pointer.

Also note that the check itself doesn't protect debug_show_held_locks()
from printing garbage, as there's nothing that keeps a task from
becoming runnable a nanosecond after we've run the task_is_running()
check. In fact I'd argue that it's better to make this function
*more* racy, for the simple robustness reason that we absolutely
do not want it to crash even in the racy case.

TL;DR: it should be fine to print the held locks of running
tasks too, as long as we print out a warning when we print
such a task, so that users are aware of any racy output.

The (lightly tested) patch below implements this.

Note that this way there's no need to gate this on the Syzkaller
config option, and you wouldn't have to carry it in -next either,
it's a useful mainline kernel debuggability enhancement in its
own right.

Would this work for you?

Thanks,

	Ingo

=================>
From: Ingo Molnar <mingo@kernel.org>
Date: Sun, 5 Jul 2026 10:38:06 +0200
Subject: [PATCH] lockdep: Enable the printing of held locks of running non-current tasks

Currently lockdep does not print out the held locks of non-current
tasks that are running (on some other CPU), due to the fact that
the held locks array is in flux and may be unreliable to print.

Syzkaller on the other hand found it that the analysis of locking
bugs is easier if we print this information too, because the
more locking information the merrier. In particular races are
bound to have multiple tasks running on different CPUs, and
the exclusion of their held locks information is unnecessarily
limiting.

So while it's still true that printing out their held locks
array is racy, it's not as bad as it seems.

There's 16 internal callers to lockdep_print_held_locks():

 - 14 callers call it with the current task, which should be
   safe out of box.

 - 1 caller, debug_show_all_locks(), calls it with RCU held,
   which should guarantee that 'p' cannot go away under us.

 - 1 caller, debug_show_held_locks(), exposes the internal API
   with the constraint that it should only be called by drivers
   or platform code if the task isn't actively running - we can
   assume that if it nevertheless does, it will be Their Problem™.

As for held locks being changed from under debug_show_held_locks(),
while the task cannot go away, so the held-locks array itself is
safe (although potentially non-stable), AFAICS the worst-case race
can be garbage printed out by print_lock(), not any actual crashes.

In particular:

        unsigned int class_idx = hlock->class_idx;

may be stale (belong to a lock that already got released on another
CPU), but it should still be a valid class index bound by
MAX_LOCKDEP_KEYS, and thus the lock_classes_in_use bitmap use
should be safe.

The other two accesses are ::acquire_ip and ::instance:

       printk(KERN_CONT "%px", hlock->instance);
       print_lock_name(hlock, lock);
       printk(KERN_CONT ", at: %pS\n", (void *)hlock->acquire_ip);

But both are printed out as pointers, so no risk of dereference
of a dangling pointer. We may print a garbage pointer.

Also note that the check itself doesn't protect debug_show_held_locks()
from printing garbage, as there's nothing that keeps a task from
becoming runnable a nanosecond after we've run the task_is_running()
check. In fact I'd argue that it's better to make this function
*more* racy, for the simple robustness reason that we absolutely
do not want it to crash even in the racy case.

TL;DR: it should be fine to print the held locks of running
tasks too, as long as we print out a warning when we print
such a task, so that users are aware of any racy output.

This commit implements that change.

For running tasks, the printout adds a warning about the
fact that the task is running and that the held locks array
is in flux:

  5 locks held by bash/1234 (WARNING: task running):
  ...

Note that while re-flowing the function this change also
micro-optimizes the common !depth case, which unnecessarily
ran through the runnability check and the (zero-steps) loop.

Reported-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
 kernel/locking/lockdep.c | 19 ++++++++++++-------
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index 2d4c5bab5af8..4b193bdc8552 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -786,18 +786,23 @@ static void print_lock(struct held_lock *hlock)
 static void lockdep_print_held_locks(struct task_struct *p)
 {
 	int i, depth = READ_ONCE(p->lockdep_depth);
+	const char *msg_running = "";
 
-	if (!depth)
+	if (!depth) {
 		printk("no locks held by %s/%d.\n", p->comm, task_pid_nr(p));
-	else
-		printk("%d lock%s held by %s/%d:\n", depth,
-		       str_plural(depth), p->comm, task_pid_nr(p));
+		return;
+	}
+
 	/*
-	 * It's not reliable to print a task's held locks if it's not sleeping
-	 * and it's not the current task.
+	 * It's not reliable to print a task's held locks if it's not
+	 * sleeping and it's not the current task:
 	 */
 	if (p != current && task_is_running(p))
-		return;
+		msg_running = " (WARNING: task running)";
+
+	printk("%d lock%s held by %s/%d%s:\n", depth,
+	       str_plural(depth), p->comm, task_pid_nr(p), msg_running);
+
 	for (i = 0; i < depth; i++) {
 		printk(" #%d: ", i);
 		print_lock(p->held_locks + i);

Re: [PATCH] lockdep: Enable the printing of held locks of running non-current tasks

[Tetsuo Handa]

On 2026/07/05 18:05, Ingo Molnar wrote:
> TL;DR: it should be fine to print the held locks of running
> tasks too, as long as we print out a warning when we print
> such a task, so that users are aware of any racy output.
> 
> The (lightly tested) patch below implements this.
> 
> Note that this way there's no need to gate this on the Syzkaller
> config option, and you wouldn't have to carry it in -next either,
> it's a useful mainline kernel debuggability enhancement in its
> own right.
> 
> Would this work for you?

Yes, this will be a helpful change. Thank you very much.
I can drop "locking/lockdep: make lockdep_print_held_locks() always print
if CONFIG_DEBUG_AID_FOR_SYZBOT=y" change from linux-next tree.

Please avoid emitting "BUG:" or "WARNING:", for syzkaller stops upon
encountering these strings. Also, since printk() is a slow operation,
please reduce number of characters to print where reasonable.

-		msg_running = " (WARNING: task running)";
+		msg_running = " (running)";

If we can safely calculate on which CPU that thread is running (or waiting
to run), printing CPU number might be also helpful.

	char msg_running[14] = "";

	if (task_is_running(p)) {
		int cpu_id = which_cpu_task_is_on(p); // If possible...

		if (cpu_id >= 0)
			scnprintf(msg_running, sizeof(msg_running), "(C%u)", cpu_id);
		else
			scnprintf(msg_running, sizeof(msg_running), "(running)");
	}

[PATCH -v2] lockdep: Enable the printing of held locks of remote running tasks and print task CPU

[Ingo Molnar]

* Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> wrote:

> On 2026/07/05 18:05, Ingo Molnar wrote:
> > TL;DR: it should be fine to print the held locks of running
> > tasks too, as long as we print out a warning when we print
> > such a task, so that users are aware of any racy output.
> > 
> > The (lightly tested) patch below implements this.
> > 
> > Note that this way there's no need to gate this on the Syzkaller
> > config option, and you wouldn't have to carry it in -next either,
> > it's a useful mainline kernel debuggability enhancement in its
> > own right.
> > 
> > Would this work for you?
> 
> Yes, this will be a helpful change. Thank you very much.
> I can drop "locking/lockdep: make lockdep_print_held_locks() always print
> if CONFIG_DEBUG_AID_FOR_SYZBOT=y" change from linux-next tree.
> 
> Please avoid emitting "BUG:" or "WARNING:", for syzkaller stops upon
> encountering these strings. Also, since printk() is a slow operation,
> please reduce number of characters to print where reasonable.
> 
> -		msg_running = " (WARNING: task running)";
> +		msg_running = " (running)";
> 
> If we can safely calculate on which CPU that thread is running (or waiting
> to run), printing CPU number might be also helpful.
> 
> 	char msg_running[14] = "";
> 
> 	if (task_is_running(p)) {
> 		int cpu_id = which_cpu_task_is_on(p); // If possible...
> 
> 		if (cpu_id >= 0)

[ Side note: task_cpu() is never negative and can always be relied on
  for valid tasks to be an int in the possible-CPUs numeric range. ]

> 			scnprintf(msg_running, sizeof(msg_running), "(C%u)", cpu_id);
> 		else
> 			scnprintf(msg_running, sizeof(msg_running), "(running)");
> 	}

Sure, we can print the CPU ID too, in fact we can do something even
better: for locking races it's useful information on which CPU
a task last ran on, right? So I think we should just print the CPU ID
of tasks unconditionally.

The patch below does this, and also streamlines the printout a bit,
into a single statement. The new message variants are:

  [   37.078569] locks held by sleep/7991: 1, on CPU#2:
  [   37.083565] locks held by sleep/7995: 1, on CPU#3:
  [   37.086346] locks held by sleep/7997: 5, last CPU#2:
  [   37.096518] locks held by sleep/8001: 6, last CPU#0
  [   37.056812] locks held by bash/414: 0, last CPU#0

See the patch description and the extended comment in the code
about the details.

I've applied this patch to tip:locking/debug, so it should
show up in -next tomorrow, but it can be iterated some more.

Thanks,

	Ingo

================================>
From: Ingo Molnar <mingo@kernel.org>
Date: Sun, 5 Jul 2026 11:05:17 +0200
Subject: [PATCH] lockdep: Enable the printing of held locks of remote running tasks and print task CPU

Background:
==========

Currently lockdep does not print out the held locks of non-current
tasks that are running on some other CPU, due to the fact that
the held locks array is in flux and may be unreliable to print.

Syzkaller on the other hand found it that the analysis of locking
bugs is easier if we print this information too, because the
more locking information the merrier. In particular races are
bound to have multiple tasks running on different CPUs, and
the exclusion of their held locks information is unnecessarily
limiting.

So while it's still true that printing out their held locks
array is racy, it's not as bad as it seems.

There's 16 internal callers to lockdep_print_held_locks():

 - 14 callers call it with the current task, which should be
   safe out of box.

 - 1 caller, debug_show_all_locks(), calls it with RCU held,
   which should guarantee that 'p' cannot go away under us.

 - 1 caller, debug_show_held_locks(), exposes the internal API
   with the constraint that it should only be called by drivers
   or platform code if the task isn't actively running - we can
   assume that if it nevertheless does, it will be Their Problem™.

As for held locks being changed from under debug_show_held_locks(),
while the task cannot go away, so the held-locks array itself is
safe (although potentially non-stable), AFAICS the worst-case race
can be garbage printed out by print_lock(), not any actual crashes.

In particular:

        unsigned int class_idx = hlock->class_idx;

may be stale (belong to a lock that already got released on another
CPU), but it should still be a valid class index bound by
MAX_LOCKDEP_KEYS, and thus the lock_classes_in_use bitmap use
should be safe.

The other two accesses are ::acquire_ip and ::instance:

       printk(KERN_CONT "%px", hlock->instance);
       print_lock_name(hlock, lock);
       printk(KERN_CONT ", at: %pS\n", (void *)hlock->acquire_ip);

But both are printed out as pointers, so no risk of dereference
of a dangling pointer. We may print a garbage pointer.

Also note that the check itself doesn't protect debug_show_held_locks()
from printing garbage, as there's nothing that keeps a task from
becoming runnable a nanosecond after we've run the task_is_running()
check. In fact I'd argue that it's better to make this function
*more* racy, for the simple robustness reason that we absolutely
do not want it to crash even in the racy case.

TL;DR: it should be fine to print the held locks of running
tasks too, as long as we print out a warning when we print
such a task, so that users are aware of any racy output.

Implementation:
==============

Implement that change.

Also re-flow the function and streamline the printout into
a single statement for all cases, which changes
the 'no locks held by' / '%d lock[s] held by' phrasing that had a
dependency on English spelling of plurals, to a uniform:

	locks held by bash/1234: %d

Which spells correctly for 0, 1 and higher values, and should also
be easier to parse both for humans and for scripts.

Finally, print out the last CPU a task has ran on. This is very
useful information for races and for locking bugs in particular.
This basically extends the 'on CPU#%d' message we print for
running tasks to all tasks we print.

Reported-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Suggested-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Boqun Feng <boqun@kernel.org>
Cc: Gary Guo <gary@garyguo.net>
Cc: Mark Brown <broonie@kernel.org>
Cc: Theodore Tso <tytso@mit.edu>
Cc: Miguel Ojeda <ojeda@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Will Deacon <will@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Waiman Long <longman@redhat.com>
Link: https://patch.msgid.link/akoeSIQGwqd9cZwd@gmail.com
---
 kernel/locking/lockdep.c | 34 +++++++++++++++++++++++++---------
 1 file changed, 25 insertions(+), 9 deletions(-)

diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index 2d4c5bab5af8..ff4bbf14665e 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -787,17 +787,33 @@ static void lockdep_print_held_locks(struct task_struct *p)
 {
 	int i, depth = READ_ONCE(p->lockdep_depth);
 
-	if (!depth)
-		printk("no locks held by %s/%d.\n", p->comm, task_pid_nr(p));
-	else
-		printk("%d lock%s held by %s/%d:\n", depth,
-		       str_plural(depth), p->comm, task_pid_nr(p));
 	/*
-	 * It's not reliable to print a task's held locks if it's not sleeping
-	 * and it's not the current task.
+	 * Note that it's always somewhat unreliable to print held locks
+	 * of a task that is running on another CPU, but we cannot guarantee
+	 * the stability of ->held_locks without actually stopping all active
+	 * remote CPUs, which we absolutely do not want to do because it's
+	 * very intrusive and thus slow.
+	 *
+	 * So we do the next best thing here: we print out the held lock
+	 * array on a best-effort basis, without crashing even if the
+	 * fields are being modified on another CPU. Note the careful
+	 * construction of print_lock() so that it never crashes.
+	 *
+	 * We also print out the CPU the task is or was last running on, with
+	 * the message saying 'on CPU...' if the task is running, and
+	 * 'last CPU' if it's not.
+	 *
+	 * Also note that the task_is_running(p) information is fundamentally
+	 * racy: even if the message says the task is 'on CPU', the task may
+	 * have scheduled out already, or if it says 'last CPU', it may just
+	 * have scheduled in on another CPU. But even with these limitations
+	 * it's still useful debuggining information.
 	 */
-	if (p != current && task_is_running(p))
-		return;
+	printk("locks held by %s/%d: %d, %s CPU#%d%s\n",
+		p->comm, task_pid_nr(p), depth,
+		task_is_running(p) ? "last" : "on", task_cpu(p),
+		depth > 0 ? ":" : "");
+
 	for (i = 0; i < depth; i++) {
 		printk(" #%d: ", i);
 		print_lock(p->held_locks + i);

Re: Policy regarding linux-next only changes

[Boqun Feng]

On Sat, Jul 04, 2026 at 07:14:32PM +0900, Tetsuo Handa wrote:
> On 2026/07/02 23:11, Boqun Feng wrote:
> >>> 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@I-love.SAKURA.ne.jp
> >>   https://lkml.kernel.org/r/7e0d2bbf-71c2-395c-9a42-d3d6d3ee4fa4@i-love.sakura.ne.jp
> >>
> > 
> > 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?
> 
> I don't remember whether some discussions are done somewhere else. But judging from
> the fact that code remains unchanged, nobody else has attempted or succeeded to
> make this change.
> 

Maybe we have some misunderstanding here, I'm not following you. Nobody
else has attempted or succeeded to make the change maybe because the
change is not important to anyone else. So if you want to make that
chagne, you are kinda responsible to keep the communication going. If
the communication stopped since 6 years ago, I cannot think of anyone
better than you should bring back the communication, but silently
putting it in linux-next is certainly not the right way. Since you
stopped reposting the patch 6 years ago, people may think your problem
has been resolved in other ways. 

Yes, it can be frustrating sometimes (maybe always :)), when you have to
keep remindering people about an issue, but this is the nature of the
human being communication. People ignore conversations for mutliple
reasons: too busy, losing interests, getting interrupted, wanting to get
a proper response but getting interrupted, etc. So if you think the
topic is important, we are looking forwards to your help to drive the
communication. Thank you!

[...]

> > 
> > 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?
> 
> I'm fine with announcing to ML that I am about to make debug/temporary changes.

You should have in this case, until Gary raised this up, it was poorly
communicatd (because there is no intent to communicate).

Regards,
Boqun

> But we might want a prefix for debug/temporary patches that are not intended for upstream?
> Also, we might want a kernel config option (e.g. CONFIG_DEBUG_AID_FOR_SYZBOT) for
> minimizing users affected?
> 

Re: Policy regarding linux-next only changes

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1684 bytes --]

On Thu, Jul 02, 2026 at 12:49:39PM +0100, Gary Guo wrote:

> 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@kernel.org/ 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.

Yes, the idea is that -next should normally just have things that are
currently intended to go to Linus by the end of the next merge window.
Obviously there's some flexability, especially for things that are
within the tree itself, but we're trying to get a heads up on things
we'll see in mainline not just do random experimental stuff.  I'd
especially not to see people putting in changes specific to other trees
without some coordination with the maintainers of the other trees.

> Perhaps these changes should also be in a separate topic branch which gets
> pulled from linux-next temporarily.

People do sometimes ask to put separate trees in for things like this,
it does depend a bit on how the branch that goes into -next is
constructed.  Some trees put a merge of various branches into -next but
send the individual branches to Linus for example, they can just add
something to their merge easily enough.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]