* [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
* Missing signoff in the bpf-next tree
From: Mark Brown @ 2026-07-07 10:30 UTC (permalink / raw)
To: Daniel Borkmann, Alexei Starovoitov, Andrii Nakryiko, bpf,
Networking
Cc: linux-kernel, linux-next
[-- Attachment #1: Type: text/plain, Size: 136 bytes --]
Commit
83a93e3b80bd3 ("selftests/bpf: libarena: Replace leftover st_ prefix with test_")
is missing a Signed-off-by from its author
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Fixes tags need work in the drm tree
From: Mark Brown @ 2026-07-07 11:52 UTC (permalink / raw)
To: Dave Airlie, DRI; +Cc: linux-kernel, linux-next
[-- Attachment #1: Type: text/plain, Size: 317 bytes --]
In commit
3b1f4d5e47b36 ("drm/amd/display: Fix dangling pointer in connector reset function")
Fixes tag
Fixes: e7b07ceef2a6 ("drm/amd/display: Merge amdgpu_dm_crtc and dm_crtc_state")
has these problem(s):
- Subject does not match target commit subject
Just use
git log -1 --format='Fixes: %h ("%s")'
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Fixes tags need work in the drm tree
From: Mark Brown @ 2026-07-07 11:53 UTC (permalink / raw)
To: Dave Airlie, DRI; +Cc: linux-kernel, linux-next
[-- Attachment #1: Type: text/plain, Size: 312 bytes --]
In commit
0aeed866cb938 ("drm/amd/display: Fix dangling pointer in CRTC reset function")
Fixes tag
Fixes: e7b07ceef2a6 ("drm/amd/display: Merge amdgpu_dm_crtc and dm_crtc_state")
has these problem(s):
- Subject does not match target commit subject
Just use
git log -1 --format='Fixes: %h ("%s")'
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* linux-next: manual merge of the risc-v tree with the mm-unstable tree
From: Mark Brown @ 2026-07-07 11:54 UTC (permalink / raw)
To: Palmer Dabbelt, Paul Walmsley
Cc: Andrew Morton, Linux Kernel Mailing List, Linux Next Mailing List,
Paul Walmsley, Usama Arif, Vivian Wang
[-- Attachment #1: Type: text/plain, Size: 1357 bytes --]
Hi all,
Today's linux-next merge of the risc-v tree got a conflict in:
arch/riscv/Kconfig
between commit:
4cc0dab993a81 ("mm: rename ARCH_ENABLE_THP_MIGRATION to ARCH_HAS_PMD_SOFTLEAVES")
from the mm-unstable tree and commit:
798246e5edfb3 ("riscv: acpi: Enable ARCH_HAS_ACPI_TABLE_UPGRADE")
from the risc-v 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 arch/riscv/Kconfig
index 2b7b69e383835,cb3d85abf595a..0000000000000
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@@ -22,7 -22,8 +22,8 @@@ config RISC
select ARCH_ENABLE_HUGEPAGE_MIGRATION if HUGETLB_PAGE && MIGRATION
select ARCH_ENABLE_MEMORY_HOTPLUG if SPARSEMEM_VMEMMAP
select ARCH_ENABLE_SPLIT_PMD_PTLOCK if PGTABLE_LEVELS > 2
- select ARCH_ENABLE_THP_MIGRATION if TRANSPARENT_HUGEPAGE
+ select ARCH_HAS_PMD_SOFTLEAVES if TRANSPARENT_HUGEPAGE
+ select ARCH_HAS_ACPI_TABLE_UPGRADE if ACPI
select ARCH_HAS_BINFMT_FLAT
select ARCH_HAS_CC_CAN_LINK
select ARCH_HAS_CURRENT_STACK_POINTER
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* linux-next: build warnings after merge of the kvm-arm-fixes tree
From: Mark Brown @ 2026-07-07 12:11 UTC (permalink / raw)
To: Oliver Upton, Marc Zyngier
Cc: Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 2480 bytes --]
Hi all,
After merging the kvm-arm-fixes tree, today's linux-next build
(arm64 defconfig) started generating warnings:
In file included from /tmp/next/build/include/linux/limits.h:7,
from /tmp/next/build/include/linux/overflow.h:6,
from /tmp/next/build/include/linux/bits.h:32,
from /tmp/next/build/arch/arm64/include/asm/kvm_pgtable.h:10,
from /tmp/next/build/arch/arm64/kvm/hyp/pgtable.c:11:
/tmp/next/build/arch/arm64/kvm/hyp/pgtable.c: In function 'kvm_pgtable_stage2_relax_perms':
/tmp/next/build/include/vdso/limits.h:8:25: warning: overflow in conversion from 'int' to 's8' {aka 'signed char'} changes value from '2147483647' to '-1' [-Woverflow]
8 | #define INT_MAX ((int)(~0U >> 1))
| ^
/tmp/next/build/arch/arm64/include/asm/tlbflush.h:131:33: note: in expansion of macro 'INT_MAX'
131 | #define TLBI_TTL_UNKNOWN INT_MAX
| ^~~~~~~
/tmp/next/build/arch/arm64/kvm/hyp/pgtable.c:1361:20: note: in expansion of macro 'TLBI_TTL_UNKNOWN'
1361 | s8 level = TLBI_TTL_UNKNOWN;
| ^~~~~~~~~~~~~~~~
In file included from /tmp/next/build/include/linux/limits.h:7,
from /tmp/next/build/include/linux/overflow.h:6,
from /tmp/next/build/include/linux/bits.h:32,
from /tmp/next/build/arch/arm64/include/asm/kvm_pgtable.h:10,
from /tmp/next/build/arch/arm64/kvm/hyp/nvhe/../pgtable.c:11:
/tmp/next/build/arch/arm64/kvm/hyp/nvhe/../pgtable.c: In function 'kvm_pgtable_stage2_relax_perms':
/tmp/next/build/include/vdso/limits.h:8:25: warning: overflow in conversion from 'int' to 's8' {aka 'signed char'} changes value from '2147483647' to '-1' [-Woverflow]
8 | #define INT_MAX ((int)(~0U >> 1))
| ^
/tmp/next/build/arch/arm64/include/asm/tlbflush.h:131:33: note: in expansion of macro 'INT_MAX'
131 | #define TLBI_TTL_UNKNOWN INT_MAX
| ^~~~~~~
/tmp/next/build/arch/arm64/kvm/hyp/nvhe/../pgtable.c:1361:20: note: in expansion of macro 'TLBI_TTL_UNKNOWN'
1361 | s8 level = TLBI_TTL_UNKNOWN;
| ^~~~~~~~~~~~~~~~
Caused by commit
100baf0184896 (KVM: arm64: Ensure level is always initialized when relaxing perms)
I imagine this will cause an allyesconfig build failure when I get to
that due to -Werror.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* linux-next: Build failure in the final build
From: Mark Brown @ 2026-07-07 12:58 UTC (permalink / raw)
To: Oliver Upton, Marc Zyngier
Cc: Linux Kernel Mailing List, Linux Next Mailing List
In-Reply-To: <akztC7H2IsEKaq4i@sirena.org.uk>
[-- Attachment #1: Type: text/plain, Size: 2710 bytes --]
On Tue, Jul 07, 2026 at 01:11:55PM +0100, Mark Brown wrote:
> After merging the kvm-arm-fixes tree, today's linux-next build
> (arm64 defconfig) started generating warnings:
> In file included from /tmp/next/build/include/linux/limits.h:7,
> from /tmp/next/build/include/linux/overflow.h:6,
> from /tmp/next/build/include/linux/bits.h:32,
> from /tmp/next/build/arch/arm64/include/asm/kvm_pgtable.h:10,
> from /tmp/next/build/arch/arm64/kvm/hyp/pgtable.c:11:
> /tmp/next/build/arch/arm64/kvm/hyp/pgtable.c: In function 'kvm_pgtable_stage2_relax_perms':
> /tmp/next/build/include/vdso/limits.h:8:25: warning: overflow in conversion from 'int' to 's8' {aka 'signed char'} changes value from '2147483647' to '-1' [-Woverflow]
> 8 | #define INT_MAX ((int)(~0U >> 1))
> | ^
> /tmp/next/build/arch/arm64/include/asm/tlbflush.h:131:33: note: in expansion of macro 'INT_MAX'
> 131 | #define TLBI_TTL_UNKNOWN INT_MAX
> | ^~~~~~~
> /tmp/next/build/arch/arm64/kvm/hyp/pgtable.c:1361:20: note: in expansion of macro 'TLBI_TTL_UNKNOWN'
> 1361 | s8 level = TLBI_TTL_UNKNOWN;
> | ^~~~~~~~~~~~~~~~
> In file included from /tmp/next/build/include/linux/limits.h:7,
> from /tmp/next/build/include/linux/overflow.h:6,
> from /tmp/next/build/include/linux/bits.h:32,
> from /tmp/next/build/arch/arm64/include/asm/kvm_pgtable.h:10,
> from /tmp/next/build/arch/arm64/kvm/hyp/nvhe/../pgtable.c:11:
> /tmp/next/build/arch/arm64/kvm/hyp/nvhe/../pgtable.c: In function 'kvm_pgtable_stage2_relax_perms':
> /tmp/next/build/include/vdso/limits.h:8:25: warning: overflow in conversion from 'int' to 's8' {aka 'signed char'} changes value from '2147483647' to '-1' [-Woverflow]
> 8 | #define INT_MAX ((int)(~0U >> 1))
> | ^
> /tmp/next/build/arch/arm64/include/asm/tlbflush.h:131:33: note: in expansion of macro 'INT_MAX'
> 131 | #define TLBI_TTL_UNKNOWN INT_MAX
> | ^~~~~~~
> /tmp/next/build/arch/arm64/kvm/hyp/nvhe/../pgtable.c:1361:20: note: in expansion of macro 'TLBI_TTL_UNKNOWN'
> 1361 | s8 level = TLBI_TTL_UNKNOWN;
> | ^~~~~~~~~~~~~~~~
> Caused by commit
> 100baf0184896 (KVM: arm64: Ensure level is always initialized when relaxing perms)
> I imagine this will cause an allyesconfig build failure when I get to
> that due to -Werror.
Confirmed, nothing later in the merge fixed the warning so -Werror
triggered breaking arm64 allyesconfig.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* linux-next: Tree for Jul 7
From: Mark Brown @ 2026-07-07 13:01 UTC (permalink / raw)
To: Linux Next Mailing List; +Cc: Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 1723 bytes --]
Hi all,
Changes since 20260706:
The risc-v tree acquired a conflict with the mm-unstable tree.
The kvm-arm-fixes tree acquired a build failure in the final build.
Non-merge commits (relative to Linus' tree): 3756
3863 files changed, 138425 insertions(+), 72637 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: [PATCH -v2] lockdep: Enable the printing of held locks of remote running tasks and print task CPU
From: Tetsuo Handa @ 2026-07-07 13:10 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, Theodore Tso
In-Reply-To: <akyopXs1SeH6rXu4@gmail.com>
On 2026/07/07 16:20, 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.
Is there a warning we print out?
We dropped WARNING: in this version, didn't we?
>
> 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.
I like this change. Thank you. ;-)
# echo t > /proc/sysrq-trigger; sleep 3; dmesg -c | cut -b 15-
Before:
Showing all locks held in the system:
4 locks held by pr/legacy/16:
1 lock held by rcub/1/18:
#0: ffffffff92ba36c8 (rcu_state){+.+.}-{0:0}, at: rcu_boost_kthread+0x15c/0x5d0
3 locks held by bash/1221:
#0: ffff8cd5dd8df500 (sb_writers#3){.+.+}-{0:0}, at: ksys_write+0x9a/0x150
#1: ffffffff92b9e080 (rcu_read_lock){....}-{1:3}, at: __handle_sysrq+0x56/0x140
#2: ffffffff92b9e080 (rcu_read_lock){....}-{1:3}, at: debug_show_all_locks+0x3d/0x184
After:
Showing all locks held in the system:
locks held by pr/legacy/16: 4, last CPU#0:
#0: ffffffffaaf9a4a0 (console_lock){+.+.}-{0:0}, at: legacy_kthread_func+0x85/0x190
#1: ffffffffaaf9a4f8 (console_srcu){....}-{0:0}, at: console_flush_one_record+0x92/0x710
#2: ffffffffab1fb818 (printing_lock){+.+.}-{3:3}, at: vt_console_print+0x74/0x640
#3: ffffffffaaf9e080 (rcu_read_lock){....}-{1:3}, at: rt_spin_trylock+0x61/0x140
locks held by rcub/1/18: 1, on CPU#0:
#0: ffffffffaafa36c8 (rcu_state){+.+.}-{0:0}, at: rcu_boost_kthread+0x15c/0x5d0
locks held by bash/1206: 3, last CPU#0:
#0: ffff8c62894da500 (sb_writers#3){.+.+}-{0:0}, at: ksys_write+0x9a/0x150
#1: ffffffffaaf9e080 (rcu_read_lock){....}-{1:3}, at: __handle_sysrq+0x56/0x140
#2: ffffffffaaf9e080 (rcu_read_lock){....}-{1:3}, at: debug_show_all_locks+0x3d/0x184
^ permalink raw reply
* Re: linux-next: build warnings after merge of the kvm-arm-fixes tree
From: Marc Zyngier @ 2026-07-07 13:17 UTC (permalink / raw)
To: Mark Brown
Cc: Oliver Upton, Linux Kernel Mailing List, Linux Next Mailing List
In-Reply-To: <akztC7H2IsEKaq4i@sirena.org.uk>
On Tue, 07 Jul 2026 13:11:55 +0100,
Mark Brown <broonie@kernel.org> wrote:
>
> Hi all,
>
> After merging the kvm-arm-fixes tree, today's linux-next build
> (arm64 defconfig) started generating warnings:
>
> In file included from /tmp/next/build/include/linux/limits.h:7,
> from /tmp/next/build/include/linux/overflow.h:6,
> from /tmp/next/build/include/linux/bits.h:32,
> from /tmp/next/build/arch/arm64/include/asm/kvm_pgtable.h:10,
> from /tmp/next/build/arch/arm64/kvm/hyp/pgtable.c:11:
> /tmp/next/build/arch/arm64/kvm/hyp/pgtable.c: In function 'kvm_pgtable_stage2_relax_perms':
> /tmp/next/build/include/vdso/limits.h:8:25: warning: overflow in conversion from 'int' to 's8' {aka 'signed char'} changes value from '2147483647' to '-1' [-Woverflow]
> 8 | #define INT_MAX ((int)(~0U >> 1))
> | ^
> /tmp/next/build/arch/arm64/include/asm/tlbflush.h:131:33: note: in expansion of macro 'INT_MAX'
> 131 | #define TLBI_TTL_UNKNOWN INT_MAX
> | ^~~~~~~
> /tmp/next/build/arch/arm64/kvm/hyp/pgtable.c:1361:20: note: in expansion of macro 'TLBI_TTL_UNKNOWN'
> 1361 | s8 level = TLBI_TTL_UNKNOWN;
> | ^~~~~~~~~~~~~~~~
> In file included from /tmp/next/build/include/linux/limits.h:7,
> from /tmp/next/build/include/linux/overflow.h:6,
> from /tmp/next/build/include/linux/bits.h:32,
> from /tmp/next/build/arch/arm64/include/asm/kvm_pgtable.h:10,
> from /tmp/next/build/arch/arm64/kvm/hyp/nvhe/../pgtable.c:11:
> /tmp/next/build/arch/arm64/kvm/hyp/nvhe/../pgtable.c: In function 'kvm_pgtable_stage2_relax_perms':
> /tmp/next/build/include/vdso/limits.h:8:25: warning: overflow in conversion from 'int' to 's8' {aka 'signed char'} changes value from '2147483647' to '-1' [-Woverflow]
> 8 | #define INT_MAX ((int)(~0U >> 1))
> | ^
> /tmp/next/build/arch/arm64/include/asm/tlbflush.h:131:33: note: in expansion of macro 'INT_MAX'
> 131 | #define TLBI_TTL_UNKNOWN INT_MAX
> | ^~~~~~~
> /tmp/next/build/arch/arm64/kvm/hyp/nvhe/../pgtable.c:1361:20: note: in expansion of macro 'TLBI_TTL_UNKNOWN'
> 1361 | s8 level = TLBI_TTL_UNKNOWN;
> | ^~~~~~~~~~~~~~~~
>
>
> Caused by commit
>
> 100baf0184896 (KVM: arm64: Ensure level is always initialized when relaxing perms)
>
> I imagine this will cause an allyesconfig build failure when I get to
> that due to -Werror.
Crap, I don't know how I missed that one! And the whole thing is
pretty dodgy anyway:
- level starts as s8
- passed to __kvm_tlb_flush_vmid_ipa_nsh() as int
- passed to __tlbi_level() as u32
- compared to the value 3
The problem is that we are conflating the level of a descriptor and
the TTL, which may or may not be related.
I'm minded to queue something like this on top. Oliver?
Thanks for the heads up,
M.
diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
index 8754c99c22f2f..70dceb20dfada 100644
--- a/arch/arm64/kvm/hyp/pgtable.c
+++ b/arch/arm64/kvm/hyp/pgtable.c
@@ -1356,7 +1356,7 @@ int kvm_pgtable_stage2_relax_perms(struct kvm_pgtable *pgt, u64 addr,
enum kvm_pgtable_prot prot, enum kvm_pgtable_walk_flags flags)
{
kvm_pte_t xn = 0, set = 0, clr = 0;
- s8 level = TLBI_TTL_UNKNOWN;
+ s8 level;
int ret;
if (prot & KVM_PTE_LEAF_ATTR_HI_SW)
@@ -1379,7 +1379,8 @@ int kvm_pgtable_stage2_relax_perms(struct kvm_pgtable *pgt, u64 addr,
ret = stage2_update_leaf_attrs(pgt, addr, 1, set, clr, NULL, &level, flags);
if (!ret || ret == -EAGAIN)
- kvm_call_hyp(__kvm_tlb_flush_vmid_ipa_nsh, pgt->mmu, addr, level);
+ kvm_call_hyp(__kvm_tlb_flush_vmid_ipa_nsh, pgt->mmu, addr,
+ (ret == -EAGAIN) ? TLBI_TTL_UNKNOWN : level);
return ret;
}
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply related
* Re: linux-next: build warnings after merge of the kvm-arm-fixes tree
From: Oliver Upton @ 2026-07-07 15:44 UTC (permalink / raw)
To: Marc Zyngier
Cc: Mark Brown, Linux Kernel Mailing List, Linux Next Mailing List
In-Reply-To: <867bn7os67.wl-maz@kernel.org>
On Tue, Jul 07, 2026 at 02:17:20PM +0100, Marc Zyngier wrote:
> On Tue, 07 Jul 2026 13:11:55 +0100,
> Mark Brown <broonie@kernel.org> wrote:
> >
> > Hi all,
> >
> > After merging the kvm-arm-fixes tree, today's linux-next build
> > (arm64 defconfig) started generating warnings:
> >
> > In file included from /tmp/next/build/include/linux/limits.h:7,
> > from /tmp/next/build/include/linux/overflow.h:6,
> > from /tmp/next/build/include/linux/bits.h:32,
> > from /tmp/next/build/arch/arm64/include/asm/kvm_pgtable.h:10,
> > from /tmp/next/build/arch/arm64/kvm/hyp/pgtable.c:11:
> > /tmp/next/build/arch/arm64/kvm/hyp/pgtable.c: In function 'kvm_pgtable_stage2_relax_perms':
> > /tmp/next/build/include/vdso/limits.h:8:25: warning: overflow in conversion from 'int' to 's8' {aka 'signed char'} changes value from '2147483647' to '-1' [-Woverflow]
> > 8 | #define INT_MAX ((int)(~0U >> 1))
> > | ^
> > /tmp/next/build/arch/arm64/include/asm/tlbflush.h:131:33: note: in expansion of macro 'INT_MAX'
> > 131 | #define TLBI_TTL_UNKNOWN INT_MAX
> > | ^~~~~~~
> > /tmp/next/build/arch/arm64/kvm/hyp/pgtable.c:1361:20: note: in expansion of macro 'TLBI_TTL_UNKNOWN'
> > 1361 | s8 level = TLBI_TTL_UNKNOWN;
> > | ^~~~~~~~~~~~~~~~
> > In file included from /tmp/next/build/include/linux/limits.h:7,
> > from /tmp/next/build/include/linux/overflow.h:6,
> > from /tmp/next/build/include/linux/bits.h:32,
> > from /tmp/next/build/arch/arm64/include/asm/kvm_pgtable.h:10,
> > from /tmp/next/build/arch/arm64/kvm/hyp/nvhe/../pgtable.c:11:
> > /tmp/next/build/arch/arm64/kvm/hyp/nvhe/../pgtable.c: In function 'kvm_pgtable_stage2_relax_perms':
> > /tmp/next/build/include/vdso/limits.h:8:25: warning: overflow in conversion from 'int' to 's8' {aka 'signed char'} changes value from '2147483647' to '-1' [-Woverflow]
> > 8 | #define INT_MAX ((int)(~0U >> 1))
> > | ^
> > /tmp/next/build/arch/arm64/include/asm/tlbflush.h:131:33: note: in expansion of macro 'INT_MAX'
> > 131 | #define TLBI_TTL_UNKNOWN INT_MAX
> > | ^~~~~~~
> > /tmp/next/build/arch/arm64/kvm/hyp/nvhe/../pgtable.c:1361:20: note: in expansion of macro 'TLBI_TTL_UNKNOWN'
> > 1361 | s8 level = TLBI_TTL_UNKNOWN;
> > | ^~~~~~~~~~~~~~~~
> >
> >
> > Caused by commit
> >
> > 100baf0184896 (KVM: arm64: Ensure level is always initialized when relaxing perms)
> >
> > I imagine this will cause an allyesconfig build failure when I get to
> > that due to -Werror.
>
> Crap, I don't know how I missed that one! And the whole thing is
> pretty dodgy anyway:
>
> - level starts as s8
> - passed to __kvm_tlb_flush_vmid_ipa_nsh() as int
> - passed to __tlbi_level() as u32
> - compared to the value 3
>
> The problem is that we are conflating the level of a descriptor and
> the TTL, which may or may not be related.
>
> I'm minded to queue something like this on top. Oliver?
>
> Thanks for the heads up,
>
> M.
>
> diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
> index 8754c99c22f2f..70dceb20dfada 100644
> --- a/arch/arm64/kvm/hyp/pgtable.c
> +++ b/arch/arm64/kvm/hyp/pgtable.c
> @@ -1356,7 +1356,7 @@ int kvm_pgtable_stage2_relax_perms(struct kvm_pgtable *pgt, u64 addr,
> enum kvm_pgtable_prot prot, enum kvm_pgtable_walk_flags flags)
> {
> kvm_pte_t xn = 0, set = 0, clr = 0;
> - s8 level = TLBI_TTL_UNKNOWN;
> + s8 level;
> int ret;
>
> if (prot & KVM_PTE_LEAF_ATTR_HI_SW)
> @@ -1379,7 +1379,8 @@ int kvm_pgtable_stage2_relax_perms(struct kvm_pgtable *pgt, u64 addr,
>
> ret = stage2_update_leaf_attrs(pgt, addr, 1, set, clr, NULL, &level, flags);
> if (!ret || ret == -EAGAIN)
> - kvm_call_hyp(__kvm_tlb_flush_vmid_ipa_nsh, pgt->mmu, addr, level);
> + kvm_call_hyp(__kvm_tlb_flush_vmid_ipa_nsh, pgt->mmu, addr,
> + (ret == -EAGAIN) ? TLBI_TTL_UNKNOWN : level);
Looks good, sorry for the mess.
Reviewed-by: Oliver Upton <oupton@kernel.org>
Thanks,
Oliver
^ permalink raw reply
* [STATUS] next/master - 5c73cd9f0819c1c44e373e3dabb68318b1de1a12
From: KernelCI bot @ 2026-07-08 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/5c73cd9f0819c1c44e373e3dabb68318b1de1a12/
giturl: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
branch: master
commit hash: 5c73cd9f0819c1c44e373e3dabb68318b1de1a12
origin: maestro
test start time: 2026-07-07 13:29:20.780000+00:00
Builds: 66 ✅ 2 ❌ 0 ⚠️
Boots: 107 ✅ 2 ❌ 0 ⚠️
Tests: 22321 ✅ 1396 ❌ 3272 ⚠️
### POSSIBLE REGRESSIONS
Hardware: hamoa-evk
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.futex
last run: https://d.kernelci.org/test/maestro:6a4d094b06fecb7f47490dc4
history: > ✅ > ✅ > ❌
- kselftest.futex.futex_run_sh_global_requeue_multiple
last run: https://d.kernelci.org/test/maestro:6a4d34e906fecb7f4749e7f9
history: > ✅ > ✅ > ❌
- kselftest.futex.futex_run_sh_global_requeue_single
last run: https://d.kernelci.org/test/maestro:6a4d34e906fecb7f4749e7fa
history: > ✅ > ✅ > ❌
- kselftest.timers.timers_set-timer-lat
last run: https://d.kernelci.org/test/maestro:6a4d39cb06fecb7f4749eb45
history: > ✅ > ❌
Hardware: kaanapali-mtp
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.futex
last run: https://d.kernelci.org/test/maestro:6a4d096306fecb7f47490e34
history: > ✅ > ✅ > ❌
- kselftest.futex.futex_run_sh_global_requeue_multiple
last run: https://d.kernelci.org/test/maestro:6a4d13fe06fecb7f47496736
history: > ✅ > ✅ > ❌
- kselftest.futex.futex_run_sh_global_requeue_single
last run: https://d.kernelci.org/test/maestro:6a4d13fe06fecb7f4749670e
history: > ✅ > ✅ > ❌
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:6a4d14de06fecb7f47496af5
history: > ✅ > ❌ > ❌
- kselftest.futex
last run: https://d.kernelci.org/test/maestro:6a4d095406fecb7f47490dd3
history: > ✅ > ✅ > ❌
- kselftest.futex.futex_run_sh_global_requeue_multiple
last run: https://d.kernelci.org/test/maestro:6a4d14fc06fecb7f47496b97
history: > ✅ > ✅ > ❌
- kselftest.futex.futex_run_sh_global_requeue_single
last run: https://d.kernelci.org/test/maestro:6a4d14fc06fecb7f47496b98
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:6a4d091f06fecb7f47490d01
history: > ✅ > ❌ > ❌ > ❌
- kselftest.futex
last run: https://d.kernelci.org/test/maestro:6a4d095b06fecb7f47490dd9
history: > ✅ > ✅ > ❌
- kselftest.futex.futex_run_sh_global_requeue_multiple
last run: https://d.kernelci.org/test/maestro:6a4d2f7f06fecb7f4749ddbe
history: > ✅ > ❌
- kselftest.futex.futex_run_sh_global_requeue_single
last run: https://d.kernelci.org/test/maestro:6a4d2f7f06fecb7f4749dde4
history: > ✅ > ✅ > ❌
Hardware: sm8750-mtp
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.futex
last run: https://d.kernelci.org/test/maestro:6a4d095f06fecb7f47490e31
history: > ✅ > ✅ > ❌
- kselftest.futex.futex_run_sh_global_requeue_multiple
last run: https://d.kernelci.org/test/maestro:6a4d157706fecb7f474973ae
history: > ✅ > ❌
- kselftest.futex.futex_run_sh_global_requeue_single
last run: https://d.kernelci.org/test/maestro:6a4d157706fecb7f474973af
history: > ✅ > ❌
Hardware: qcs8300-ride
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.futex
last run: https://d.kernelci.org/test/maestro:6a4d095806fecb7f47490dd6
history: > ✅ > ❌ > ❌
- kselftest.futex.futex_run_sh_global_requeue_multiple
last run: https://d.kernelci.org/test/maestro:6a4d1de806fecb7f4749b426
history: > ✅ > ✅ > ❌
- kselftest.futex.futex_run_sh_global_requeue_single
last run: https://d.kernelci.org/test/maestro:6a4d1de806fecb7f4749b427
history: > ✅ > ✅ > ❌
- kselftest.timers
last run: https://d.kernelci.org/test/maestro:6a4d09b206fecb7f47490f56
history: > ✅ > ❌ > ❌
- kselftest.timers.timers_rtcpie
last run: https://d.kernelci.org/test/maestro:6a4d225806fecb7f4749c371
history: > ✅ > ❌ > ❌
Hardware: glymur-crd
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_geniqup_ac0000_i2c_a80000_touchscreen_38
last run: https://d.kernelci.org/test/maestro:6a4d214d06fecb7f4749c085
history: > ✅ > ❌
### FIXED REGRESSIONS
Hardware: qcs6490-rb3gen2
> Config: defconfig+arm64-chromebook+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.gpio
last run: https://d.kernelci.org/test/maestro:6a4d0f0406fecb7f474955f2
history: > ❌ > ❌ > ✅
Hardware: qcs9100-ride
> Config: defconfig+arm64-chromebook+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.ring-buffer
last run: https://d.kernelci.org/test/maestro:6a4d0f2206fecb7f474956cf
history: > ❌ > ❌ > ✅
Hardware: qcs8300-ride
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.arm64
last run: https://d.kernelci.org/test/maestro:6a4d08c806fecb7f4748e392
history: > ❌ > ✅
- kselftest.arm64.arm64_hwcap_sigbus_LSE2
last run: https://d.kernelci.org/test/maestro:6a4d156006fecb7f47497166
history: > ❌ > ✅
> Config: defconfig+arm64-chromebook+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.gpio
last run: https://d.kernelci.org/test/maestro:6a4d0f0506fecb7f474955f5
history: > ❌ > ❌ > ✅
### UNSTABLE TESTS
Hardware: x1e80100
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.timers
last run: https://d.kernelci.org/test/maestro:6a4d09ca06fecb7f47490fba
history: > ❌ > ✅ > ❌
- kselftest.timers.timers_rtcpie
last run: https://d.kernelci.org/test/maestro:6a4d29a406fecb7f4749d2e5
history: > ❌ > ✅ > ❌
Hardware: qcs8300-ride
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.futex.futex_run_sh_args_t_5000_broadcast_owner_futex_requeue_pi
last run: https://d.kernelci.org/test/maestro:6a4d1de806fecb7f4749b443
history: > ✅ > ❌ > ✅
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
* [REGRESSION] drm/amd/display: amdgpu_dm_plane_test.ko fails to build due to modpost "too long symbol"
From: Venkat Rao Bagalkote @ 2026-07-08 5:05 UTC (permalink / raw)
To: amd-gfx
Cc: dri-devel, alexander.deucher, george.zhang, bhawanpreet.lakha,
LKML, Madhavan Srinivasan, christian.koenig, harry.wentland,
sunpeng.li, broonie, Christophe Leroy (CS GROUP),
Linux Next Mailing List
Greetings!!!
linux-next is failing to build for me with:
ERROR: modpost: too long symbol
"amdgpu_dm_plane_fill_gfx9_plane_attributes_from_modifiers"
[drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/tests/amdgpu_dm_plane_test.ko]
make[2]: *** [scripts/Makefile.modpost:147: Module.symvers] Error 1
make[1]: *** [Makefile:2165: modpost] Error 2
make: *** [Makefile:248: __sub-make] Error 2
The failure occurs during modpost while building:
drivers/gpu/drm/amd/display/amdgpu_dm/tests/amdgpu_dm_plane_test.ko
This appears to be a regression in the AMD display KUnit test code.
Could someone please take a look?
If you happen to fix this, please add below tag.
Reported-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
Regards,
Venkat.
^ permalink raw reply
* Re: [PATCH -v2] lockdep: Enable the printing of held locks of remote running tasks and print task CPU
From: Ingo Molnar @ 2026-07-08 8:37 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: <90133e2c-60aa-456f-b2a8-d0af19b02395@I-love.SAKURA.ne.jp>
* Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> wrote:
> On 2026/07/07 16:20, 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.
>
> Is there a warning we print out?
> We dropped WARNING: in this version, didn't we?
Indeed - I fixed the changelog.
> > 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.
>
> I like this change. Thank you. ;-)
>
> # echo t > /proc/sysrq-trigger; sleep 3; dmesg -c | cut -b 15-
>
> Before:
>
> Showing all locks held in the system:
> 4 locks held by pr/legacy/16:
> 1 lock held by rcub/1/18:
> #0: ffffffff92ba36c8 (rcu_state){+.+.}-{0:0}, at: rcu_boost_kthread+0x15c/0x5d0
> 3 locks held by bash/1221:
> #0: ffff8cd5dd8df500 (sb_writers#3){.+.+}-{0:0}, at: ksys_write+0x9a/0x150
> #1: ffffffff92b9e080 (rcu_read_lock){....}-{1:3}, at: __handle_sysrq+0x56/0x140
> #2: ffffffff92b9e080 (rcu_read_lock){....}-{1:3}, at: debug_show_all_locks+0x3d/0x184
>
> After:
>
> Showing all locks held in the system:
> locks held by pr/legacy/16: 4, last CPU#0:
> #0: ffffffffaaf9a4a0 (console_lock){+.+.}-{0:0}, at: legacy_kthread_func+0x85/0x190
> #1: ffffffffaaf9a4f8 (console_srcu){....}-{0:0}, at: console_flush_one_record+0x92/0x710
> #2: ffffffffab1fb818 (printing_lock){+.+.}-{3:3}, at: vt_console_print+0x74/0x640
> #3: ffffffffaaf9e080 (rcu_read_lock){....}-{1:3}, at: rt_spin_trylock+0x61/0x140
> locks held by rcub/1/18: 1, on CPU#0:
> #0: ffffffffaafa36c8 (rcu_state){+.+.}-{0:0}, at: rcu_boost_kthread+0x15c/0x5d0
> locks held by bash/1206: 3, last CPU#0:
> #0: ffff8c62894da500 (sb_writers#3){.+.+}-{0:0}, at: ksys_write+0x9a/0x150
> #1: ffffffffaaf9e080 (rcu_read_lock){....}-{1:3}, at: __handle_sysrq+0x56/0x140
> #2: ffffffffaaf9e080 (rcu_read_lock){....}-{1:3}, at: debug_show_all_locks+0x3d/0x184
Great, and you are welcome.
I've added your Tested-by tag as well, and graduated the updated
commit to tip:locking/core, to be merged into v7.3 if everything
goes fine.
Thanks,
Ingo
^ permalink raw reply
* Missing signoff in the xfs tree
From: Mark Brown @ 2026-07-08 11:03 UTC (permalink / raw)
To: David Chinner, Carlos Maiolino, linux-xfs; +Cc: linux-kernel, linux-next
[-- Attachment #1: Type: text/plain, Size: 134 bytes --]
Commit
92d2d133c6cb3 ("xfs: fail recovery on a committed log item with no regions")
is missing a Signed-off-by from its committer
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Missing signoff in the landlock tree
From: Mark Brown @ 2026-07-08 11:04 UTC (permalink / raw)
To: Mickaël Salaün; +Cc: linux-kernel, linux-next
[-- Attachment #1: Type: text/plain, Size: 124 bytes --]
Commit
12d39e0ef753e ("landlock: Document fs.resolve_unix audit blocker")
is missing a Signed-off-by from its committer
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* linux-next: manual merge of the vfs-brauner tree with the origin tree
From: Mark Brown @ 2026-07-08 11:04 UTC (permalink / raw)
To: Christian Brauner; +Cc: Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 1712 bytes --]
Hi all,
Today's linux-next merge of the vfs-brauner tree got conflicts in:
tools/testing/selftests/filesystems/Makefile
tools/testing/selftests/filesystems/.gitignore
between commit:
d943e68edc5cb ("selftests/filesystems: test O_TMPFILE creation on idmapped mounts")
from the origin tree and commit:
a21db4dcaf4ad ("selftests/filesystems: add ustat() coverage")
from the vfs-brauner 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/filesystems/.gitignore
index a78f894157de3,1bd53d54553c1..0000000000000
--- a/tools/testing/selftests/filesystems/.gitignore
+++ b/tools/testing/selftests/filesystems/.gitignore
@@@ -5,4 -5,4 +5,5 @@@ fclo
file_stressor
anon_inode_test
kernfs_test
+idmapped_tmpfile
+ ustat_test
diff --cc tools/testing/selftests/filesystems/Makefile
index a7ec2ba2dd833,bbdd40b167fac..0000000000000
--- a/tools/testing/selftests/filesystems/Makefile
+++ b/tools/testing/selftests/filesystems/Makefile
@@@ -1,8 -1,7 +1,8 @@@
# SPDX-License-Identifier: GPL-2.0
CFLAGS += $(KHDR_INCLUDES)
- TEST_GEN_PROGS := devpts_pts file_stressor anon_inode_test kernfs_test fclog
+ TEST_GEN_PROGS := devpts_pts file_stressor anon_inode_test kernfs_test fclog ustat_test
+TEST_GEN_PROGS += idmapped_tmpfile
TEST_GEN_PROGS_EXTENDED := dnotify_test
include ../lib.mk
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* linux-next: manual merge of the vfs-brauner tree with the origin tree
From: Mark Brown @ 2026-07-08 11:25 UTC (permalink / raw)
To: Christian Brauner; +Cc: Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 3928 bytes --]
Hi all,
Today's linux-next merge of the vfs-brauner tree got a conflict in:
fs/bpf_fs_kfuncs.c
between commit:
3f8c65b06fafc ("bpf: have bpf_real_data_inode() take a struct file")
from the origin tree and commit:
b4e124d168552 ("fs: Add bpf_sock_read_xattr() kfunc to read socket xattrs")
from the vfs-brauner 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 fs/bpf_fs_kfuncs.c
index f1863a891db64,9a4ea5c9b0c94..0000000000000
--- a/fs/bpf_fs_kfuncs.c
+++ b/fs/bpf_fs_kfuncs.c
@@@ -359,24 -360,52 +360,57 @@@ __bpf_kfunc int bpf_cgroup_read_xattr(s
}
#endif /* CONFIG_CGROUPS */
+ #ifdef CONFIG_NET
+ /**
+ * bpf_sock_read_xattr - read xattr of a socket's inode in sockfs
+ * @sock: socket to get xattr from
+ * @name__str: name of the xattr
+ * @value_p: output buffer of the xattr value
+ *
+ * Get xattr *name__str* of *sock* and store the output in *value_p*.
+ *
+ * For security reasons, only *name__str* with prefix "user." is allowed.
+ *
+ * Return: length of the xattr value on success, a negative value on error.
+ */
+ __bpf_kfunc int bpf_sock_read_xattr(struct socket *sock, const char *name__str,
+ struct bpf_dynptr *value_p)
+ {
+ struct bpf_dynptr_kern *value_ptr = (struct bpf_dynptr_kern *)value_p;
+ u32 value_len;
+ void *value;
+
+ /* Only allow reading "user.*" xattrs */
+ if (strncmp(name__str, XATTR_USER_PREFIX, XATTR_USER_PREFIX_LEN))
+ return -EPERM;
+
+ value_len = __bpf_dynptr_size(value_ptr);
+ value = __bpf_dynptr_data_rw(value_ptr, value_len);
+ if (!value)
+ return -EINVAL;
+
+ return sock_read_xattr(sock, name__str, value, value_len);
+ }
+ #endif /* CONFIG_NET */
+
/**
- * bpf_real_inode - get the real inode backing a dentry
- * @dentry: dentry to resolve
+ * bpf_real_data_inode - get the real inode hosting a file's data
+ * @file: file to resolve
*
- * If the dentry is on a union/overlay filesystem, return the underlying, real
- * inode that hosts the data. Otherwise return the inode attached to the
- * dentry itself.
+ * Resolve @file to the inode that hosts its data. For a regular file on a
+ * union/overlay filesystem this is the underlying (upper or lower) inode that
+ * stores the data, not the overlay inode.
*
- * Return: The real inode backing the dentry, or NULL for a negative dentry.
+ * Data resolution only applies to regular files. For a non-regular file (e.g.
+ * a device node, fifo or socket) on a union/overlay filesystem the overlay
+ * inode itself is returned; for any file on a non-union filesystem the inode
+ * attached to @file is returned.
+ *
+ * Return: The inode hosting @file's data, or NULL.
*/
-__bpf_kfunc struct inode *bpf_real_inode(struct dentry *dentry)
+__bpf_kfunc struct inode *bpf_real_data_inode(struct file *file)
{
- return d_real_inode(dentry);
+ return d_real_inode(file_dentry(file));
}
__bpf_kfunc_end_defs();
@@@ -389,7 -418,10 +423,10 @@@ BTF_ID_FLAGS(func, bpf_get_dentry_xattr
BTF_ID_FLAGS(func, bpf_get_file_xattr, KF_SLEEPABLE)
BTF_ID_FLAGS(func, bpf_set_dentry_xattr, KF_SLEEPABLE)
BTF_ID_FLAGS(func, bpf_remove_dentry_xattr, KF_SLEEPABLE)
-BTF_ID_FLAGS(func, bpf_real_inode, KF_SLEEPABLE | KF_RET_NULL)
+BTF_ID_FLAGS(func, bpf_real_data_inode, KF_SLEEPABLE | KF_RET_NULL)
+ #ifdef CONFIG_NET
+ BTF_ID_FLAGS(func, bpf_sock_read_xattr, KF_RCU)
+ #endif
BTF_KFUNCS_END(bpf_fs_kfunc_set_ids)
static int bpf_fs_kfuncs_filter(const struct bpf_prog *prog, u32 kfunc_id)
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: Missing signoff in the xfs tree
From: Carlos Maiolino @ 2026-07-08 12:42 UTC (permalink / raw)
To: Mark Brown; +Cc: David Chinner, linux-xfs, linux-kernel, linux-next
In-Reply-To: <ak4uhSXlLF3Gr576@sirena.org.uk>
On Wed, Jul 08, 2026 at 12:03:33PM +0100, Mark Brown wrote:
> Commit
>
> 92d2d133c6cb3 ("xfs: fail recovery on a committed log item with no regions")
>
> is missing a Signed-off-by from its committer
woops, I'll fix it
^ permalink raw reply
* Re: Missing signoff in the xfs tree
From: Carlos Maiolino @ 2026-07-08 12:57 UTC (permalink / raw)
To: Mark Brown; +Cc: David Chinner, linux-xfs, linux-kernel, linux-next
In-Reply-To: <ak4uhSXlLF3Gr576@sirena.org.uk>
On Wed, Jul 08, 2026 at 12:03:33PM +0100, Mark Brown wrote:
> Commit
>
> 92d2d133c6cb3 ("xfs: fail recovery on a committed log item with no regions")
>
> is missing a Signed-off-by from its committer
Updated it, thanks for the heads up
^ permalink raw reply
* linux-next: manual merge of the kvm tree with the tip tree
From: Mark Brown @ 2026-07-08 14:59 UTC (permalink / raw)
To: Paolo Bonzini, KVM
Cc: Borislav Petkov, Linux Kernel Mailing List,
Linux Next Mailing List, Sean Christopherson
[-- Attachment #1: Type: text/plain, Size: 1340 bytes --]
Hi all,
Today's linux-next merge of the kvm tree got a conflict in:
arch/x86/kvm/x86.c
between commit:
3eaa50e1e255e ("x86/cpu: Hide and rename static_cpu_has()")
from the tip tree and commit:
7a26830801584 ("KVM: x86: Move the bulk of MSR specific code from x86.c to msrs.{c,h}")
from the kvm 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 arch/x86/kvm/x86.c
index 63daa4dfa23ad,0626e835e9eb7..0000000000000
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
diff --git a/arch/x86/kvm/msrs.c b/arch/x86/kvm/msrs.c
index c230b18d87e38..861d04bfa63dd 100644
--- a/arch/x86/kvm/msrs.c
+++ b/arch/x86/kvm/msrs.c
@@ -651,7 +651,7 @@ static int set_efer(struct kvm_vcpu *vcpu, struct msr_data *msr_info)
if ((efer ^ old_efer) & KVM_MMU_EFER_ROLE_BITS)
kvm_mmu_reset_context(vcpu);
- if (!static_cpu_has(X86_FEATURE_XSAVES) &&
+ if (!cpu_feature_enabled(X86_FEATURE_XSAVES) &&
(efer & EFER_SVME))
kvm_hv_xsaves_xsavec_maybe_warn(vcpu);
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related
* linux-next: Tree for Jul 8
From: Mark Brown @ 2026-07-08 14:59 UTC (permalink / raw)
To: Linux Next Mailing List; +Cc: Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 1715 bytes --]
Hi all,
Changes since 20260707:
The vfs-brauner tree acquired multiple conflicts with the origin tree.
The kvm tree acquired a conflict with the tip tree.
Non-merge commits (relative to Linus' tree): 4101
4181 files changed, 144964 insertions(+), 74828 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: linux-next: manual merge of the kvm tree with the tip tree
From: Borislav Petkov @ 2026-07-08 17:31 UTC (permalink / raw)
To: Mark Brown, Paolo Bonzini, KVM
Cc: Linux Kernel Mailing List, Linux Next Mailing List,
Sean Christopherson
In-Reply-To: <ak5lu6XQP6PPtQ6u@sirena.org.uk>
On July 8, 2026 2:59:07 PM UTC, Mark Brown <broonie@kernel.org> wrote:
>diff --cc arch/x86/kvm/x86.c
>index 63daa4dfa23ad,0626e835e9eb7..0000000000000
>--- a/arch/x86/kvm/x86.c
>+++ b/arch/x86/kvm/x86.c
>diff --git a/arch/x86/kvm/msrs.c b/arch/x86/kvm/msrs.c
>index c230b18d87e38..861d04bfa63dd 100644
>--- a/arch/x86/kvm/msrs.c
>+++ b/arch/x86/kvm/msrs.c
>@@ -651,7 +651,7 @@ static int set_efer(struct kvm_vcpu *vcpu, struct msr_data *msr_info)
> if ((efer ^ old_efer) & KVM_MMU_EFER_ROLE_BITS)
> kvm_mmu_reset_context(vcpu);
>
>- if (!static_cpu_has(X86_FEATURE_XSAVES) &&
>+ if (!cpu_feature_enabled(X86_FEATURE_XSAVES) &&
> (efer & EFER_SVME))
> kvm_hv_xsaves_xsavec_maybe_warn(vcpu);
Yap, LGTM.
Thx.
--
Small device. Typos and formatting crap
^ permalink raw reply
* [STATUS] next/master - b9810cd75b9fb56a3425d391cba3f608502bd474
From: KernelCI bot @ 2026-07-09 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/b9810cd75b9fb56a3425d391cba3f608502bd474/
giturl: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
branch: master
commit hash: b9810cd75b9fb56a3425d391cba3f608502bd474
origin: maestro
test start time: 2026-07-08 14:17:25.846000+00:00
Builds: 65 ✅ 1 ❌ 0 ⚠️
Boots: 67 ✅ 3 ❌ 0 ⚠️
Tests: 15820 ✅ 943 ❌ 122 ⚠️
### POSSIBLE REGRESSIONS
No possible regressions observed.
### FIXED REGRESSIONS
Hardware: qcs8300-ride
> Config: defconfig+arm64-chromebook+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.efivars
last run: https://d.kernelci.org/test/maestro:6a4e752306fecb7f474e57d7
history: > ❌ > ✅
### UNSTABLE TESTS
Hardware: qcs6490-rb3gen2
> Config: defconfig+arm64-chromebook+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.gpio
last run: https://d.kernelci.org/test/maestro:6a4e756406fecb7f474e589b
history: > ❌ > ❌ > ✅ > ❌
Hardware: qcs8300-ride
> Config: defconfig+arm64-chromebook+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.gpio
last run: https://d.kernelci.org/test/maestro:6a4e756606fecb7f474e589e
history: > ❌ > ❌ > ✅ > ❌
Hardware: qcs9100-ride
> Config: defconfig+arm64-chromebook+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.ring-buffer
last run: https://d.kernelci.org/test/maestro:6a4e758906fecb7f474e77c7
history: > ❌ > ❌ > ✅ > ❌
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
* Fixes tags need work in the drm-misc tree
From: Mark Brown @ 2026-07-09 12:33 UTC (permalink / raw)
To: Simona Vetter, Intel Graphics, DRI; +Cc: linux-kernel, linux-next
[-- Attachment #1: Type: text/plain, Size: 317 bytes --]
In commit
3b1f4d5e47b36 ("drm/amd/display: Fix dangling pointer in connector reset function")
Fixes tag
Fixes: e7b07ceef2a6 ("drm/amd/display: Merge amdgpu_dm_crtc and dm_crtc_state")
has these problem(s):
- Subject does not match target commit subject
Just use
git log -1 --format='Fixes: %h ("%s")'
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ 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