* [PATCH -v2] lockdep: Enable the printing of held locks of remote running tasks and print task CPU
From: Ingo Molnar @ 2026-07-07 7:20 UTC (permalink / raw)
To: Tetsuo Handa
Cc: Boqun Feng, Gary Guo, Mark Brown, linux-next, linux-kernel,
Miguel Ojeda, Linus Torvalds, peterz, will, longman, gregkh,
syzkaller, Theodore Tso
In-Reply-To: <2f7513c6-42e1-413b-8bd5-fa5abefe4b99@I-love.SAKURA.ne.jp>
* 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);
^ permalink raw reply related
* [STATUS] next/master - 8e9685d3c41c35dd1b37df70d854137abcb2fbac
From: KernelCI bot @ 2026-07-07 2:30 UTC (permalink / raw)
To: kernelci-results; +Cc: linux-next
Hello,
Status summary for next/master
Dashboard:
https://d.kernelci.org/c/next/master/8e9685d3c41c35dd1b37df70d854137abcb2fbac/
giturl: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
branch: master
commit hash: 8e9685d3c41c35dd1b37df70d854137abcb2fbac
origin: maestro
test start time: 2026-07-06 16:10:48.456000+00:00
Builds: 66 ✅ 2 ❌ 0 ⚠️
Boots: 107 ✅ 3 ❌ 0 ⚠️
Tests: 22586 ✅ 1379 ❌ 2817 ⚠️
### POSSIBLE REGRESSIONS
Hardware: qcs6490-rb3gen2
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_iommu_3da0000
last run: https://d.kernelci.org/test/maestro:6a4c06e106fecb7f4743b179
history: > ✅ > ❌
Hardware: qcs9100-ride
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest-device-error-logs-ramdisk
last run: https://d.kernelci.org/test/maestro:6a4c0a6d06fecb7f474434a0
history: > ✅ > ❌ > ❌
Hardware: qcs8300-ride
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.futex
last run: https://d.kernelci.org/test/maestro:6a4c032506fecb7f47439772
history: > ✅ > ❌
- kselftest.futex.futex_run_sh_args_t_5000_broadcast_owner_futex_requeue_pi
last run: https://d.kernelci.org/test/maestro:6a4c0c2f06fecb7f47443be5
history: > ✅ > ❌
- kselftest.timers
last run: https://d.kernelci.org/test/maestro:6a4c034306fecb7f474397e1
history: > ✅ > ❌
- kselftest.timers.timers_rtcpie
last run: https://d.kernelci.org/test/maestro:6a4c107f06fecb7f474446a7
history: > ✅ > ❌
### FIXED REGRESSIONS
Hardware: x1e80100
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.timers
last run: https://d.kernelci.org/test/maestro:6a4c034b06fecb7f474397fc
history: > ❌ > ✅
- kselftest.timers.timers_rtcpie
last run: https://d.kernelci.org/test/maestro:6a4c0fea06fecb7f47444506
history: > ❌ > ✅
### UNSTABLE TESTS
No unstable tests observed.
This branch has 1 pre-existing build issues. See details in the dashboard.
Sent every day if there were changes in the past 24 hours.
Legend: ✅ PASS ❌ FAIL ⚠️ INCONCLUSIVE
--
This is an experimental report format. Please send feedback in!
Talk to us at kernelci@lists.linux.dev
Made with love by the KernelCI team - https://kernelci.org
^ permalink raw reply
* -next status as at v7.2-rc2
From: Mark Brown @ 2026-07-06 18:39 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-next, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 669 bytes --]
Hi Linus,
Things are still fairly quiet, we've had a bit of instability as new
things start to flow into -next but nothing too remarkable and other
than the usual DRM cherry picking not much time to start having
conflicts.
Trees being held at old versions:
ext3 next-20260703
Trees with signoff problems:
wireless (missing committer, new today)
Non-merge commits relative to Linus' tree: 3372
3537 files changed, 159837 insertions(+), 65637 deletions(-)
Top trees adding commits to -next:
437 amdgpu
302 drm-misc
222 mm-unstable
196 drm-intel
112 vfs-brauner
95 nfsd
95 drm-xe
93 net-next
90 sound-asoc
87 tip
Thanks,
Mark
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* linux-next: Tree for Jul 6
From: Mark Brown @ 2026-07-06 18:35 UTC (permalink / raw)
To: Linux Next Mailing List; +Cc: Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 1869 bytes --]
Hi all,
Changes since 20260703:
The ext3 tree acquired a build failure, I used the version from
next-20260603 instead.
The mm-nonmm-unstable tree lost it's build failure.
The net-next tree acquired a conflict with the net tree.
The wireless tree acquired a build failure in the final build which I
ignored.
Non-merge commits (relative to Linus' tree): 3372
3537 files changed, 159837 insertions(+), 65637 deletions(-)
----------------------------------------------------------------------------
I have created today's linux-next tree at
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at https://www.kernel.org/pub/linux/kernel/next/ ). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" and checkout or reset to the new
master.
You can see which trees have been included by looking in the Next/Trees
file in the source. There is also the merge.log file in the Next
directory. Between each merge, the tree was built with a defconfig
for arm64, an allmodconfig for x86_64, a multi_v7_defconfig for arm,
an arm64 build of various kselftests, a KUnit build and run on arm64,
and a native build of tools/perf. After the final fixups (if any), I do
an x86_64 modules_install followed by builds for x86_64 allnoconfig,
arm64 allyesconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig and pseries_le_defconfig and i386, s390, sparc and
sparc64 defconfig and htmldocs.
Below is a summary of the state of the merge.
I am currently merging 427 trees (counting Linus' and 132 trees of bug
fix patches pending for the current release).
Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .
Thanks to Paul Gortmaker for triage and bug fixes.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: Policy regarding linux-next only changes
From: Mark Brown @ 2026-07-06 17:23 UTC (permalink / raw)
To: Tetsuo Handa
Cc: Miguel Ojeda, Alexander Potapenko, Boqun Feng, Gary Guo,
linux-next, linux-kernel, Miguel Ojeda, Linus Torvalds, peterz,
will, longman, mingo, gregkh
In-Reply-To: <4aecbe01-1ad8-488c-9a77-d5134def6f24@I-love.SAKURA.ne.jp>
[-- 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 --]
^ permalink raw reply
* Re: linux-next: build failure in the final build
From: Johannes Berg @ 2026-07-06 14:52 UTC (permalink / raw)
To: Jeff Chen, Francesco Dolcini, Linux Kernel Mailing List,
Linux Next Mailing List
In-Reply-To: <akvAuzqXtDrttQk7@sirena.org.uk>
On Mon, 2026-07-06 at 15:50 +0100, Mark Brown wrote:
> Hi all,
>
> In the final build, today's linux-next build (arm64 allyesconfig) failed
> like this:
>
> ld: drivers/net/wireless/nxp/nxpwifi/main.o: in function `is_command_pending':
> main.c:(.text+0xa348): multiple definition of `is_command_pending'; drivers/net/wireless/marvell/mwifiex/main.o:main.c:(.text+0xc188): first defined here
> ld: drivers/net/wireless/nxp/nxpwifi/main.o:(.data+0xa80): multiple definition of `driver_version'; drivers/net/wireless/marvell/mwifiex/main.o:(.rodata+0x2c00): first defined here
> ld: drivers/net/wireless/nxp/nxpwifi/cfp.o:(.data+0x740): multiple definition of `region_code_index'; drivers/net/wireless/marvell/mwifiex/cfp.o:(.data+0x840): first defined here
> ld: drivers/net/wireless/nxp/nxpwifi/wmm.o:(.rodata+0xda0): multiple definition of `tos_to_tid_inv'; drivers/net/wireless/marvell/mwifiex/wmm.o:(.rodata+0xe60): first defined here
>
> due to
>
> 4c477f8bfc1a8 (wifi: nxp: add nxpwifi driver for IW61x)
>
Well. I've dropped the merge then. Jeff, please resend with things fixed
up.
johannes
^ permalink raw reply
* linux-next: build failure in the final build
From: Mark Brown @ 2026-07-06 14:50 UTC (permalink / raw)
To: Jeff Chen, Francesco Dolcini, Johannes Berg
Cc: Linux Kernel Mailing List, Linux Next Mailing List
Hi all,
In the final build, today's linux-next build (arm64 allyesconfig) failed
like this:
ld: drivers/net/wireless/nxp/nxpwifi/main.o: in function `is_command_pending':
main.c:(.text+0xa348): multiple definition of `is_command_pending'; drivers/net/wireless/marvell/mwifiex/main.o:main.c:(.text+0xc188): first defined here
ld: drivers/net/wireless/nxp/nxpwifi/main.o:(.data+0xa80): multiple definition of `driver_version'; drivers/net/wireless/marvell/mwifiex/main.o:(.rodata+0x2c00): first defined here
ld: drivers/net/wireless/nxp/nxpwifi/cfp.o:(.data+0x740): multiple definition of `region_code_index'; drivers/net/wireless/marvell/mwifiex/cfp.o:(.data+0x840): first defined here
ld: drivers/net/wireless/nxp/nxpwifi/wmm.o:(.rodata+0xda0): multiple definition of `tos_to_tid_inv'; drivers/net/wireless/marvell/mwifiex/wmm.o:(.rodata+0xe60): first defined here
due to
4c477f8bfc1a8 (wifi: nxp: add nxpwifi driver for IW61x)
I have ignored that for today.
^ permalink raw reply
* linux-next: manual merge of the net-next tree with the net tree
From: Mark Brown @ 2026-07-06 13:48 UTC (permalink / raw)
To: David Miller, Jakub Kicinski, Paolo Abeni, Networking
Cc: Linux Kernel Mailing List, Linux Next Mailing List, Nirmoy Das
[-- Attachment #1: Type: text/plain, Size: 1176 bytes --]
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
tools/testing/selftests/net/lib.sh
between commit:
dd6a23bac306b ("selftests: net: make busywait timeout clock portable")
from the net tree and commit:
895bad9cc4cec ("selftests: net: make busywait timeout clock portable")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
diff --cc tools/testing/selftests/net/lib.sh
index d46d2cec89e45,d389a965d8f19..0000000000000
--- a/tools/testing/selftests/net/lib.sh
+++ b/tools/testing/selftests/net/lib.sh
@@@ -93,10 -89,8 +89,9 @@@ loopy_wait(
{
local sleep_cmd=$1; shift
local timeout_ms=$1; shift
- local start_time
+ local current_time
- start_time=$(timestamp_ms) || return
+ local start_time=$(timestamp_ms)
while true
do
local out
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* linux-next: build failure after merge of the ext3 tree
From: Mark Brown @ 2026-07-06 13:35 UTC (permalink / raw)
To: Jan Kara, Kyle Zeng; +Cc: Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 695 bytes --]
Hi all,
After merging the ext3 tree, today's linux-next build (x86_64
allmodconfig) failed like this:
/tmp/next/build/fs/udf/inode.c:2302:37: error: use of undeclared
identifier 'sbi'
2302 | if (eloc->partitionReferenceNum >= sbi->s_partitions) {
| ^
/tmp/next/build/fs/udf/inode.c:2304:35: error: use of undeclared
identifier 'sbi'
2304 | eloc->partitionReferenceNum, sbi->s_partitions);
| ^
Caused by commit
107eb175cbc81 (udf: validate extent partition references in udf_current_aext())
I have used the version from next-20260603 instead.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [Re] GPU reset when running the ROCm hsa runtime tests on gfx12 and next-20260701
From: Bert Karwatzki @ 2026-07-06 12:46 UTC (permalink / raw)
To: Alex Deucher
Cc: linux-kernel, amd-gfx, linux-next, Jesse Zhang, Amber Lin,
Mario Limonciello, spasswolf
In-Reply-To: <e3b04980fd0bc7a6c3edfcd089e8fb4c559bbf38.camel@web.de>
I found the real cause of my problems:
bool amdgpu_mes_queue_reset_by_mes_supported(struct amdgpu_device *adev)
{
u32 ip_maj = IP_VERSION_MAJ(amdgpu_ip_version(adev, GC_HWIP, 0));
u32 ip_min = IP_VERSION_MIN(amdgpu_ip_version(adev, GC_HWIP, 0));
u32 mes_sched = adev->mes.sched_version & AMDGPU_MES_VERSION_MASK;
printk(KERN_INFO "%s: ip_maj = %u ip_min = %u mes_sched = 0x%x", __func__, ip_maj, ip_min, mes_sched);
return (ip_maj == 11 && mes_sched >= 0x8c) ||
((ip_maj == 12 && ip_min == 0) && mes_sched >= 0x8d) ||
((ip_maj == 12 && ip_min == 1) && mes_sched >= 0x73);
}
returns false on my machine (because mes_sched is not large enough)
[ T8549] amdgpu_mes_queue_reset_by_mes_supported: ip_maj = 12 ip_min = 0 mes_sched = 0x76
So I skipped the call to amdgpu_mes_queue_reset_by_mes_supported()
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
index 5c9dfb0c424f..462f20aeb681 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
@@ -448,17 +448,22 @@ static int reset_queues_mes(struct device_queue_manager *dqm, struct queue *q)
unsigned int num_hung = 0;
int r = 0;
struct mes_remove_queue_input queue_input;
+ printk(KERN_INFO "entering %s", __func__);
+ /*
if (!amdgpu_mes_queue_reset_by_mes_supported(adev)) {
r = -ENOTRECOVERABLE;
+ printk(KERN_INFO "%s: reset by mes not supported", __func__);
goto fail;
- }
+ }*/
+ printk(KERN_INFO "%s: skip calling amdgpu_mes_queue_reset_by_mes_supported()", __func__);
/* reset should be used only in dqm locked queue reset */
if (WARN_ON(dqm->detect_hang_count > 0))
return 0;
if (!amdgpu_gpu_recovery) {
+ printk(KERN_INFO "%s: gpu recovery not enabled", __func__);
r = -ENOTRECOVERABLE;
goto fail;
}
@@ -470,6 +475,7 @@ static int reset_queues_mes(struct device_queue_manager *dqm, struct queue *q)
queue_input.xcc_id = ffs(dqm->dev->xcc_mask) - 1;
/* pass the known bad queue info to the reset function */
r = amdgpu_gfx_reset_mes_compute(adev, NULL, NULL, NULL, &num_hung, &queue_input);
+ printk(KERN_INFO "%s: amdgpu_gfx_reset_mes_compute() returned %d", __func__, r);
if (r)
goto fail;
@@ -3231,6 +3237,7 @@ int kfd_dqm_suspend_bad_queue_mes(struct kfd_node *knode, u32 pasid, u32 doorbel
struct qcm_process_device *qpd;
struct queue *q = NULL;
int ret = 0;
+ printk(KERN_INFO "entering %s", __func__);
if (!pdd)
return -EINVAL;
@@ -3242,6 +3249,7 @@ int kfd_dqm_suspend_bad_queue_mes(struct kfd_node *knode, u32 pasid, u32 doorbel
list_for_each_entry(q, &qpd->queues_list, list) {
if (q->doorbell_id == doorbell_id && q->properties.is_active) {
+ printk(KERN_INFO "%s: calling recover_bad_queue_mes() for queue %px", __func__, q);
and got this output when running the hsaruntime (which inject illegal opcodes into the
command stream) test:
[ 113.811612] [ T645] [drm:gfx_v12_0_bad_op_irq [amdgpu]] *ERROR* Illegal opcode in command stream
[ 113.811675] [ T2558] entering kfd_dqm_suspend_bad_queue_mes
[ 113.811676] [ T2558] kfd_dqm_suspend_bad_queue_mes: calling recover_bad_queue_mes() for queue ffffa03160950400
[ 113.811676] [ T2558] entering reset_queues_mes
[ 113.811677] [ T2558] reset_queues_mes: skip calling amdgpu_mes_queue_reset_by_mes_supported()
[ 113.811887] [ T2558] reset_queues_mes: amdgpu_gfx_reset_mes_compute() returned 0
So even though amdgpu_mes_queue_reset_by_mes_supported() reported false,
amdgpu_gfx_reset_mes_compute() returns 0, suggesting that resetting actually works here!
Perhaps the minimum required mes_sched version for 12.0 can be relaxed to 0x76 to solve this:
From 6d7af652177063963012eb4df228e99caeb03b31 Mon Sep 17 00:00:00 2001
From: Bert Karwatzki <spasswolf@web.de>
Date: Mon, 6 Jul 2026 14:36:22 +0200
Subject: [PATCH] amdgpu: relax required mes_sched version
This mes_sched version is actually enough on this hardware:
03:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 44 [Radeon RX 9060 XT] [1002:7590] (rev c0)
[ 3.200538] [ T537] amdgpu 0000:03:00.0: initializing kernel modesetting (IP DISCOVERY 0x1002:0x7590 0x148C:0x2437 0xC0).
[ 3.200546] [ T537] amdgpu 0000:03:00.0: register mmio base: 0xDFC00000
[ 3.200547] [ T537] amdgpu 0000:03:00.0: register mmio size: 524288
[ 3.203739] [ T537] amdgpu 0000:03:00.0: detected ip block number 0 <common_v1_0_0> (soc24_common)
[ 3.203740] [ T537] amdgpu 0000:03:00.0: detected ip block number 1 <gmc_v12_0_0> (gmc_v12_0)
[ 3.203741] [ T537] amdgpu 0000:03:00.0: detected ip block number 2 <ih_v7_0_0> (ih_v7_0)
[ 3.203741] [ T537] amdgpu 0000:03:00.0: detected ip block number 3 <psp_v14_0_0> (psp)
[ 3.203742] [ T537] amdgpu 0000:03:00.0: detected ip block number 4 <smu_v14_0_0> (smu)
[ 3.203742] [ T537] amdgpu 0000:03:00.0: detected ip block number 5 <dce_v1_0_0> (dm)
[ 3.203743] [ T537] amdgpu 0000:03:00.0: detected ip block number 6 <gfx_v12_0_0> (gfx_v12_0)
[ 3.203743] [ T537] amdgpu 0000:03:00.0: detected ip block number 7 <sdma_v7_0_0> (sdma_v7_0)
[ 3.203744] [ T537] amdgpu 0000:03:00.0: detected ip block number 8 <vcn_v5_0_0> (vcn_v5_0_0)
[ 3.203744] [ T537] amdgpu 0000:03:00.0: detected ip block number 9 <jpeg_v5_0_0> (jpeg_v5_0_0)
[ 3.203745] [ T537] amdgpu 0000:03:00.0: detected ip block number 10 <mes_v12_0_0> (mes_v12_0)
Signed-off-by: Bert Karwatzki <spasswolf@web.de>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c
index 6c0dde3786e3..c88fdc8a187d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c
@@ -869,7 +869,7 @@ bool amdgpu_mes_queue_reset_by_mes_supported(struct amdgpu_device *adev)
u32 mes_sched = adev->mes.sched_version & AMDGPU_MES_VERSION_MASK;
return (ip_maj == 11 && mes_sched >= 0x8c) ||
- ((ip_maj == 12 && ip_min == 0) && mes_sched >= 0x8d) ||
+ ((ip_maj == 12 && ip_min == 0) && mes_sched >= 0x76) ||
((ip_maj == 12 && ip_min == 1) && mes_sched >= 0x73);
}
--
2.53.0
Bert Karwatzki
^ permalink raw reply related
* Missing signoff in the wireless tree
From: Mark Brown @ 2026-07-06 12:08 UTC (permalink / raw)
To: Johannes Berg, Wireless; +Cc: linux-kernel, linux-next
[-- Attachment #1: Type: text/plain, Size: 136 bytes --]
Commit
e4fa2545a610d ("wifi: cfg80211: cancel sched scan results work on unregister")
is missing a Signed-off-by from its committer
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [Re] GPU reset when running the ROCm hsa runtime tests on gfx12 and next-20260701
From: Bert Karwatzki @ 2026-07-05 22:45 UTC (permalink / raw)
To: Alex Deucher
Cc: linux-kernel, amd-gfx, linux-next, Jesse Zhang, Amber Lin,
Mario Limonciello, spasswolf
In-Reply-To: <20260705003504.31425-1-spasswolf@web.de>
Am Sonntag, dem 05.07.2026 um 02:35 +0200 schrieb Bert Karwatzki:
> I identified the problem in
> f94bbd648bb4 ("drm/amdgpu: use a single entry point for mes compute reset")
> it's reset_queues_mes() being called unconditionally. f94bbd648bb4 can be fixed
> like this:
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> index 6054c8e216b8..ed1ffa8b1743 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> @@ -484,15 +484,18 @@ static int suspend_all_queues_mes(struct device_queue_manager *dqm)
> if (!down_read_trylock(&adev->reset_domain->sem))
> return -EIO;
>
> + r = amdgpu_mes_suspend(adev, ffs(dqm->dev->xcc_mask) - 1);
>
> - if (!reset_queues_mes(dqm)) {
> - r = 0;
> - goto out;
> - }
> + if (r) {
> + if (!reset_queues_mes(dqm)) {
> + r = 0;
> + goto out;
> + }
>
> - dev_err(adev->dev, "failed to suspend gangs from MES\n");
> - dev_err(adev->dev, "MES might be in unrecoverable state, issue a GPU reset\n");
> - kfd_hws_hang(dqm);
> + dev_err(adev->dev, "failed to suspend gangs from MES\n");
> + dev_err(adev->dev, "MES might be in unrecoverable state, issue a GPU reset\n");
> + kfd_hws_hang(dqm);
> + }
> out:
>
> up_read(&adev->reset_domain->sem);
>
>
> But when I try to fix next-20260701 like this
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> index 5c9dfb0c424f..5a78b1504f8c 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> @@ -493,7 +493,10 @@ static int recover_bad_queue_mes(struct device_queue_manager *dqm, struct queue
> if (!down_read_trylock(&adev->reset_domain->sem))
> return -EIO;
>
> - r = reset_queues_mes(dqm, q);
> + r = amdgpu_mes_suspend(adev, ffs(dqm->dev->xcc_mask) - 1);
> +
> + if (r)
> + r = reset_queues_mes(dqm, q);
>
> up_read(&adev->reset_domain->sem);
> return r;
>
> I still get GPUVM errors (but no GPU reset) and when running
>
> $ /usr/libexec/rocm/libhsa-runtime64-tests/run-tests
>
> [ 146.577245] [ T418] amdgpu 0000:03:00.0: [gfxhub] page fault (src_id:0 ring:157 vmid:0 pasid:0)
> [ 146.577247] [ T418] amdgpu 0000:03:00.0: in page starting at address 0x00000000002ba000 from client 10
> [ 146.577248] [ T418] amdgpu 0000:03:00.0: GCVM_L2_PROTECTION_FAULT_STATUS:0x00000B3A
> [ 146.577249] [ T418] amdgpu 0000:03:00.0: Faulty UTCL2 client ID: CPC (0x5)
> [ 146.577249] [ T418] amdgpu 0000:03:00.0: MORE_FAULTS: 0x0
> [ 146.577250] [ T418] amdgpu 0000:03:00.0: WALKER_ERROR: 0x5
> [ 146.577250] [ T418] amdgpu 0000:03:00.0: PERMISSION_FAULTS: 0x3
> [ 146.577250] [ T418] amdgpu 0000:03:00.0: MAPPING_ERROR: 0x1
> [ 146.577251] [ T418] amdgpu 0000:03:00.0: RW: 0x0
> [ 146.577606] [ T418] amdgpu 0000:03:00.0: [gfxhub] page fault (src_id:0 ring:157 vmid:0 pasid:0)
> [ 146.577608] [ T418] amdgpu 0000:03:00.0: in page starting at address 0x00000000002ba000 from client 10
> [ 146.577609] [ T418] amdgpu 0000:03:00.0: GCVM_L2_PROTECTION_FAULT_STATUS:0x00000B3A
> [ 146.577609] [ T418] amdgpu 0000:03:00.0: Faulty UTCL2 client ID: CPC (0x5)
> [ 146.577610] [ T418] amdgpu 0000:03:00.0: MORE_FAULTS: 0x0
> [ 146.577611] [ T418] amdgpu 0000:03:00.0: WALKER_ERROR: 0x5
> [ 146.577611] [ T418] amdgpu 0000:03:00.0: PERMISSION_FAULTS: 0x3
> [ 146.577611] [ T418] amdgpu 0000:03:00.0: MAPPING_ERROR: 0x1
> [ 146.577612] [ T418] amdgpu 0000:03:00.0: RW: 0x0
>
> This means there's at least another error in these commits (reverting all these in
> next-20260701 fixes the issue)
>
> b789664e3e30 ("drm/amdkfd: Clean up suspend_all and resume_all mes")
> a665d09b10af ("drm/amdkfd: Pass known bad queue info to reset")
> a4e4d945cba8 ("drm/amdgpu/gfx: defer per-queue helper_end until after MES resume")
> f401a2633e02 ("drm/amdgpu: Remove faulty queue before resume")
> f94bbd648bb4 ("drm/amdgpu: use a single entry point for mes compute reset")
>
> Bert Karwatzki
These GPUVM error are introduce by
a665d09b10af ("drm/amdkfd: Pass known bad queue info to reset")
and can be fixed by a partial revert. a665d09b10af can be fixed by
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
index 0d95dd941129..0c49fe95a75d 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
@@ -491,15 +491,18 @@ static int suspend_all_queues_mes(struct device_queue_manager *dqm, struct queue
if (!down_read_trylock(&adev->reset_domain->sem))
return -EIO;
+ r = amdgpu_mes_suspend(adev, ffs(dqm->dev->xcc_mask) - 1);
- if (!reset_queues_mes(dqm, q)) {
- r = 0;
- goto out;
- }
+ if (r) {
+ if (!reset_queues_mes(dqm, q)) {
+ r = 0;
+ goto out;
+ }
- dev_err(adev->dev, "failed to suspend gangs from MES\n");
- dev_err(adev->dev, "MES might be in unrecoverable state, issue a GPU reset\n");
- kfd_hws_hang(dqm);
+ dev_err(adev->dev, "failed to suspend gangs from MES\n");
+ dev_err(adev->dev, "MES might be in unrecoverable state, issue a GPU reset\n");
+ kfd_hws_hang(dqm);
+ }
out:
up_read(&adev->reset_domain->sem);
@@ -3239,6 +3242,7 @@ int kfd_dqm_suspend_bad_queue_mes(struct kfd_node *knode, u32 pasid, u32 doorbel
struct kfd_process_device *pdd = NULL;
struct kfd_process *p = kfd_lookup_process_by_pasid(pasid, &pdd);
struct device_queue_manager *dqm = knode->dqm;
+ struct device *dev = dqm->dev->adev->dev;
struct qcm_process_device *qpd;
struct queue *q = NULL;
int ret = 0;
@@ -3260,6 +3264,12 @@ int kfd_dqm_suspend_bad_queue_mes(struct kfd_node *knode, u32 pasid, u32 doorbel
q->properties.is_active = false;
decrement_queue_count(dqm, qpd, q);
+ /* this will remove the bad queue and sched a GPU reset if needed */
+ ret = remove_queue_mes(dqm, q, qpd);
+ if (ret)
+ dev_err(dev, "Removing bad queue failed");
+ /* resume the good queues */
+ resume_all_queues_mes(dqm);
break;
}
}
This does not work in next-20260701 as commit
b789664e3e30 ("drm/amdkfd: Clean up suspend_all and resume_all mes")
removes resume_all_queues_mes().
Bert Karwatzki
^ permalink raw reply related
* Re: Policy regarding linux-next only changes
From: Boqun Feng @ 2026-07-05 14:59 UTC (permalink / raw)
To: Tetsuo Handa
Cc: Gary Guo, Mark Brown, linux-next, linux-kernel, Miguel Ojeda,
Linus Torvalds, peterz, will, longman, mingo, gregkh
In-Reply-To: <7f1b93a9-f756-4bfc-81d7-1350ac1d50ac@I-love.SAKURA.ne.jp>
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?
>
^ permalink raw reply
* Re: Policy regarding linux-next only changes
From: Tetsuo Handa @ 2026-07-05 14:16 UTC (permalink / raw)
To: Mark Brown, Miguel Ojeda
Cc: Alexander Potapenko, Boqun Feng, Gary Guo, linux-next,
linux-kernel, Miguel Ojeda, Linus Torvalds, peterz, will, longman,
mingo, gregkh
In-Reply-To: <akpI0IIqgXCXmQhQ@sirena.co.uk>
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.
^ permalink raw reply
* Re: linux-next: KUnit failure after merge of the mm-nonmm-unstable tree
From: Mark Brown @ 2026-07-05 12:27 UTC (permalink / raw)
To: Alexey Dobriyan
Cc: Andrew Morton, Linux Kernel Mailing List, Linux Next Mailing List
In-Reply-To: <afc8f908-4add-4da8-816c-9a6c06619b18@p183>
[-- Attachment #1: Type: text/plain, Size: 660 bytes --]
On Sat, Jul 04, 2026 at 07:55:40AM +0300, Alexey Dobriyan wrote:
> On Fri, Jul 03, 2026 at 05:39:59PM +0100, Mark Brown wrote:
> > > [14:22:11] [FAILED] cmdline_test_memparse
> > > [14:22:11] # module: cmdline_kunit
> > bisect tells me it's due to:
> > e595545005616 (Revert "lib: fix _parse_integer_limit() to handle overflow")
> No, it is due to
> commit 9a4580db6e9f83428813f671a79486469684069f
> lib: fix memparse() to handle overflow
> memparse should be rewritten with _parse_integer().
Huh, that was my first guess when I looked at the log but I didn't spot
the relevance so wanted to check then it seems the bisect got confused
somehow.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: Policy regarding linux-next only changes
From: Mark Brown @ 2026-07-05 12:20 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Tetsuo Handa, Theodore Tso, Alexander Potapenko, Boqun Feng,
Gary Guo, linux-next, linux-kernel, Miguel Ojeda, Linus Torvalds,
peterz, will, longman, mingo, gregkh
In-Reply-To: <CANiq72nNz6Xo8yu0nyC3OLAJiAA9A86a7Ku59YX0GD-cVwJnGA@mail.gmail.com>
[-- 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 --]
^ permalink raw reply
* Re: Policy regarding linux-next only changes
From: Mark Brown @ 2026-07-05 12:06 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Tetsuo Handa, Alexander Potapenko, Boqun Feng, Gary Guo,
linux-next, linux-kernel, Miguel Ojeda, Linus Torvalds, peterz,
will, longman, mingo, gregkh
In-Reply-To: <CANiq72=hLXip=gQS1tnLQxe6Kpwq03Bd8F1z_xLrdoCtvSAkfg@mail.gmail.com>
[-- 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 --]
^ permalink raw reply
* Re: Policy regarding linux-next only changes
From: Miguel Ojeda @ 2026-07-05 12:06 UTC (permalink / raw)
To: Tetsuo Handa
Cc: Theodore Tso, Alexander Potapenko, Boqun Feng, Gary Guo,
Mark Brown, linux-next, linux-kernel, Miguel Ojeda,
Linus Torvalds, peterz, will, longman, mingo, gregkh
In-Reply-To: <CANiq72nNz6Xo8yu0nyC3OLAJiAA9A86a7Ku59YX0GD-cVwJnGA@mail.gmail.com>
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
^ permalink raw reply
* Re: Policy regarding linux-next only changes
From: Miguel Ojeda @ 2026-07-05 12:02 UTC (permalink / raw)
To: Tetsuo Handa
Cc: Theodore Tso, Alexander Potapenko, Boqun Feng, Gary Guo,
Mark Brown, linux-next, linux-kernel, Miguel Ojeda,
Linus Torvalds, peterz, will, longman, mingo, gregkh
In-Reply-To: <dc3c0e2a-a3fb-496a-ac82-fff849b8ba78@I-love.SAKURA.ne.jp>
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
^ permalink raw reply
* Re: Policy regarding linux-next only changes
From: Tetsuo Handa @ 2026-07-05 11:36 UTC (permalink / raw)
To: Theodore Tso, Miguel Ojeda
Cc: Alexander Potapenko, Boqun Feng, Gary Guo, Mark Brown, linux-next,
linux-kernel, Miguel Ojeda, Linus Torvalds, peterz, will, longman,
mingo, gregkh
In-Reply-To: <akkGwsQg1k5ZfGwa@mit.edu>
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).
^ permalink raw reply
* Re: [PATCH] lockdep: Enable the printing of held locks of running non-current tasks
From: Tetsuo Handa @ 2026-07-05 11:05 UTC (permalink / raw)
To: Ingo Molnar
Cc: Boqun Feng, Gary Guo, Mark Brown, linux-next, linux-kernel,
Miguel Ojeda, Linus Torvalds, peterz, will, longman, gregkh,
syzkaller
In-Reply-To: <akoeSIQGwqd9cZwd@gmail.com>
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)");
}
^ permalink raw reply
* [PATCH] lockdep: Enable the printing of held locks of running non-current tasks (was: Policy regarding linux-next only changes)
From: Ingo Molnar @ 2026-07-05 9:05 UTC (permalink / raw)
To: Tetsuo Handa
Cc: Boqun Feng, Gary Guo, Mark Brown, linux-next, linux-kernel,
Miguel Ojeda, Linus Torvalds, peterz, will, longman, gregkh
In-Reply-To: <7f1b93a9-f756-4bfc-81d7-1350ac1d50ac@I-love.SAKURA.ne.jp>
* 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);
^ permalink raw reply related
* [Re] GPU reset when running the ROCm hsa runtime tests on gfx12 and next-20260701
From: Bert Karwatzki @ 2026-07-05 0:35 UTC (permalink / raw)
To: Alex Deucher
Cc: Bert Karwatzki, linux-kernel, amd-gfx, linux-next, Jesse Zhang,
Amber Lin, Mario Limonciello
In-Reply-To: <20260703124405.56248-1-spasswolf@web.de>
I identified the problem in
f94bbd648bb4 ("drm/amdgpu: use a single entry point for mes compute reset")
it's reset_queues_mes() being called unconditionally. f94bbd648bb4 can be fixed
like this:
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
index 6054c8e216b8..ed1ffa8b1743 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
@@ -484,15 +484,18 @@ static int suspend_all_queues_mes(struct device_queue_manager *dqm)
if (!down_read_trylock(&adev->reset_domain->sem))
return -EIO;
+ r = amdgpu_mes_suspend(adev, ffs(dqm->dev->xcc_mask) - 1);
- if (!reset_queues_mes(dqm)) {
- r = 0;
- goto out;
- }
+ if (r) {
+ if (!reset_queues_mes(dqm)) {
+ r = 0;
+ goto out;
+ }
- dev_err(adev->dev, "failed to suspend gangs from MES\n");
- dev_err(adev->dev, "MES might be in unrecoverable state, issue a GPU reset\n");
- kfd_hws_hang(dqm);
+ dev_err(adev->dev, "failed to suspend gangs from MES\n");
+ dev_err(adev->dev, "MES might be in unrecoverable state, issue a GPU reset\n");
+ kfd_hws_hang(dqm);
+ }
out:
up_read(&adev->reset_domain->sem);
But when I try to fix next-20260701 like this
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
index 5c9dfb0c424f..5a78b1504f8c 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
@@ -493,7 +493,10 @@ static int recover_bad_queue_mes(struct device_queue_manager *dqm, struct queue
if (!down_read_trylock(&adev->reset_domain->sem))
return -EIO;
- r = reset_queues_mes(dqm, q);
+ r = amdgpu_mes_suspend(adev, ffs(dqm->dev->xcc_mask) - 1);
+
+ if (r)
+ r = reset_queues_mes(dqm, q);
up_read(&adev->reset_domain->sem);
return r;
I still get GPUVM errors (but no GPU reset) and when running
$ /usr/libexec/rocm/libhsa-runtime64-tests/run-tests
[ 146.577245] [ T418] amdgpu 0000:03:00.0: [gfxhub] page fault (src_id:0 ring:157 vmid:0 pasid:0)
[ 146.577247] [ T418] amdgpu 0000:03:00.0: in page starting at address 0x00000000002ba000 from client 10
[ 146.577248] [ T418] amdgpu 0000:03:00.0: GCVM_L2_PROTECTION_FAULT_STATUS:0x00000B3A
[ 146.577249] [ T418] amdgpu 0000:03:00.0: Faulty UTCL2 client ID: CPC (0x5)
[ 146.577249] [ T418] amdgpu 0000:03:00.0: MORE_FAULTS: 0x0
[ 146.577250] [ T418] amdgpu 0000:03:00.0: WALKER_ERROR: 0x5
[ 146.577250] [ T418] amdgpu 0000:03:00.0: PERMISSION_FAULTS: 0x3
[ 146.577250] [ T418] amdgpu 0000:03:00.0: MAPPING_ERROR: 0x1
[ 146.577251] [ T418] amdgpu 0000:03:00.0: RW: 0x0
[ 146.577606] [ T418] amdgpu 0000:03:00.0: [gfxhub] page fault (src_id:0 ring:157 vmid:0 pasid:0)
[ 146.577608] [ T418] amdgpu 0000:03:00.0: in page starting at address 0x00000000002ba000 from client 10
[ 146.577609] [ T418] amdgpu 0000:03:00.0: GCVM_L2_PROTECTION_FAULT_STATUS:0x00000B3A
[ 146.577609] [ T418] amdgpu 0000:03:00.0: Faulty UTCL2 client ID: CPC (0x5)
[ 146.577610] [ T418] amdgpu 0000:03:00.0: MORE_FAULTS: 0x0
[ 146.577611] [ T418] amdgpu 0000:03:00.0: WALKER_ERROR: 0x5
[ 146.577611] [ T418] amdgpu 0000:03:00.0: PERMISSION_FAULTS: 0x3
[ 146.577611] [ T418] amdgpu 0000:03:00.0: MAPPING_ERROR: 0x1
[ 146.577612] [ T418] amdgpu 0000:03:00.0: RW: 0x0
This means there's at least another error in these commits (reverting all these in
next-20260701 fixes the issue)
b789664e3e30 ("drm/amdkfd: Clean up suspend_all and resume_all mes")
a665d09b10af ("drm/amdkfd: Pass known bad queue info to reset")
a4e4d945cba8 ("drm/amdgpu/gfx: defer per-queue helper_end until after MES resume")
f401a2633e02 ("drm/amdgpu: Remove faulty queue before resume")
f94bbd648bb4 ("drm/amdgpu: use a single entry point for mes compute reset")
Bert Karwatzki
^ permalink raw reply related
* Re: Policy regarding linux-next only changes
From: Theodore Tso @ 2026-07-04 13:22 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Tetsuo Handa, Alexander Potapenko, Boqun Feng, Gary Guo,
Mark Brown, linux-next, linux-kernel, Miguel Ojeda,
Linus Torvalds, peterz, will, longman, mingo, gregkh
In-Reply-To: <CANiq72=hLXip=gQS1tnLQxe6Kpwq03Bd8F1z_xLrdoCtvSAkfg@mail.gmail.com>
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
^ permalink raw reply
* Re: Policy regarding linux-next only changes
From: Miguel Ojeda @ 2026-07-04 12:06 UTC (permalink / raw)
To: Tetsuo Handa, Alexander Potapenko
Cc: Boqun Feng, Gary Guo, Mark Brown, linux-next, linux-kernel,
Miguel Ojeda, Linus Torvalds, peterz, will, longman, mingo,
gregkh
In-Reply-To: <7f1b93a9-f756-4bfc-81d7-1350ac1d50ac@I-love.SAKURA.ne.jp>
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
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox