* [PATCH v4 1/5] locking/lockdep: Add a helper to validate the locking context without a lock
2026-06-08 14:21 [PATCH v4 0/5] lib/vsprintf: Validate spinlock context during restricted pointer formatting Thomas Weißschuh
@ 2026-06-08 14:21 ` Thomas Weißschuh
2026-06-08 14:21 ` [PATCH v4 2/5] locking/lockdep: Add a guard for lock_map_acquire() Thomas Weißschuh
` (3 subsequent siblings)
4 siblings, 0 replies; 8+ messages in thread
From: Thomas Weißschuh @ 2026-06-08 14:21 UTC (permalink / raw)
To: Andrew Morton, Petr Mladek, Steven Rostedt, Andy Shevchenko,
Rasmus Villemoes, Sergey Senozhatsky, Peter Zijlstra, Ingo Molnar,
Will Deacon, Boqun Feng, Waiman Long, Sebastian Andrzej Siewior,
Clark Williams, Kees Cook
Cc: linux-kernel, linux-rt-devel, Thomas Weißschuh
In some cases the specific codepath and its locking operations depend on
the runtime configuration of the system. lockdep will only detect lock
misuse if the system is configured in the right way by chance.
To make lockdep more reliable in these cases, introduce a helper macro
to define a lockdep map without any corresponding lock.
This differs from the related DEFINE_WAIT_OVERRIDE_MAP() as the context
of the map is checked against the current locking context.
Link: https://lore.kernel.org/lkml/20241217142032.55793-1-acarmina@redhat.com/
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
---
include/linux/lockdep.h | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
index 621566345406..ae3e332f1518 100644
--- a/include/linux/lockdep.h
+++ b/include/linux/lockdep.h
@@ -315,6 +315,11 @@ extern void lock_unpin_lock(struct lockdep_map *lock, struct pin_cookie);
.wait_type_inner = _wait_type, \
.lock_type = LD_LOCK_WAIT_OVERRIDE, }
+#define DEFINE_WAIT_ASSERT_MAP(_name, _wait_type) \
+ struct lockdep_map _name = { \
+ .name = #_name "-wait-type-assert", \
+ .wait_type_inner = _wait_type, }
+
#else /* !CONFIG_LOCKDEP */
static inline void lockdep_init_task(struct task_struct *task)
@@ -407,6 +412,9 @@ extern int lockdep_is_held(const void *);
#define DEFINE_WAIT_OVERRIDE_MAP(_name, _wait_type) \
struct lockdep_map __maybe_unused _name = {}
+#define DEFINE_WAIT_ASSERT_MAP(_name, _wait_type) \
+ struct lockdep_map __maybe_unused _name = {}
+
#endif /* !LOCKDEP */
#ifdef CONFIG_PROVE_LOCKING
--
2.54.0
^ permalink raw reply related [flat|nested] 8+ messages in thread* [PATCH v4 2/5] locking/lockdep: Add a guard for lock_map_acquire()
2026-06-08 14:21 [PATCH v4 0/5] lib/vsprintf: Validate spinlock context during restricted pointer formatting Thomas Weißschuh
2026-06-08 14:21 ` [PATCH v4 1/5] locking/lockdep: Add a helper to validate the locking context without a lock Thomas Weißschuh
@ 2026-06-08 14:21 ` Thomas Weißschuh
2026-06-08 14:21 ` [PATCH v4 3/5] lib/vsprintf: Use in_task() for restricted pointer context check Thomas Weißschuh
` (2 subsequent siblings)
4 siblings, 0 replies; 8+ messages in thread
From: Thomas Weißschuh @ 2026-06-08 14:21 UTC (permalink / raw)
To: Andrew Morton, Petr Mladek, Steven Rostedt, Andy Shevchenko,
Rasmus Villemoes, Sergey Senozhatsky, Peter Zijlstra, Ingo Molnar,
Will Deacon, Boqun Feng, Waiman Long, Sebastian Andrzej Siewior,
Clark Williams, Kees Cook
Cc: linux-kernel, linux-rt-devel, Thomas Weißschuh
Make it easy to acquire a lock map based on source code structure.
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
---
include/linux/lockdep.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
index ae3e332f1518..fad8d71e0505 100644
--- a/include/linux/lockdep.h
+++ b/include/linux/lockdep.h
@@ -10,6 +10,7 @@
#ifndef __LINUX_LOCKDEP_H
#define __LINUX_LOCKDEP_H
+#include <linux/cleanup.h>
#include <linux/lockdep_types.h>
#include <linux/smp.h>
#include <asm/percpu.h>
@@ -553,6 +554,8 @@ do { \
#define lock_map_release(l) lock_release(l, _THIS_IP_)
#define lock_map_sync(l) lock_sync(l, 0, 0, 1, NULL, _THIS_IP_)
+DEFINE_GUARD(lock_map_acquire, struct lockdep_map *, lock_map_acquire(_T), lock_map_release(_T))
+
#ifdef CONFIG_PROVE_LOCKING
# define might_lock(lock) \
do { \
--
2.54.0
^ permalink raw reply related [flat|nested] 8+ messages in thread* [PATCH v4 3/5] lib/vsprintf: Use in_task() for restricted pointer context check
2026-06-08 14:21 [PATCH v4 0/5] lib/vsprintf: Validate spinlock context during restricted pointer formatting Thomas Weißschuh
2026-06-08 14:21 ` [PATCH v4 1/5] locking/lockdep: Add a helper to validate the locking context without a lock Thomas Weißschuh
2026-06-08 14:21 ` [PATCH v4 2/5] locking/lockdep: Add a guard for lock_map_acquire() Thomas Weißschuh
@ 2026-06-08 14:21 ` Thomas Weißschuh
2026-06-08 14:21 ` [PATCH v4 4/5] lib/vsprintf: Always check interrupt context restrictions Thomas Weißschuh
2026-06-08 14:21 ` [PATCH v4 5/5] lib/vsprintf: Validate spinlock context during restricted pointer formatting Thomas Weißschuh
4 siblings, 0 replies; 8+ messages in thread
From: Thomas Weißschuh @ 2026-06-08 14:21 UTC (permalink / raw)
To: Andrew Morton, Petr Mladek, Steven Rostedt, Andy Shevchenko,
Rasmus Villemoes, Sergey Senozhatsky, Peter Zijlstra, Ingo Molnar,
Will Deacon, Boqun Feng, Waiman Long, Sebastian Andrzej Siewior,
Clark Williams, Kees Cook
Cc: linux-kernel, linux-rt-devel, Thomas Weißschuh
in_task() is a easier to read and slightly more efficient variant of
the existing tests.
Suggested-by: Peter Zijlstra <peterz@infradead.org>
Link: https://lore.kernel.org/lkml/20260504130044.GU3126523@noisy.programming.kicks-ass.net/
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
---
lib/vsprintf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 33e0778fca52..6095b5f0d022 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -874,7 +874,7 @@ char *restricted_pointer(char *buf, char *end, const void *ptr,
* kptr_restrict==1 cannot be used in IRQ context
* because its test for CAP_SYSLOG would be meaningless.
*/
- if (in_hardirq() || in_serving_softirq() || in_nmi()) {
+ if (!in_task()) {
if (spec.field_width == -1)
spec.field_width = 2 * sizeof(ptr);
return error_string(buf, end, "pK-error", spec);
--
2.54.0
^ permalink raw reply related [flat|nested] 8+ messages in thread* [PATCH v4 4/5] lib/vsprintf: Always check interrupt context restrictions
2026-06-08 14:21 [PATCH v4 0/5] lib/vsprintf: Validate spinlock context during restricted pointer formatting Thomas Weißschuh
` (2 preceding siblings ...)
2026-06-08 14:21 ` [PATCH v4 3/5] lib/vsprintf: Use in_task() for restricted pointer context check Thomas Weißschuh
@ 2026-06-08 14:21 ` Thomas Weißschuh
2026-06-08 14:21 ` [PATCH v4 5/5] lib/vsprintf: Validate spinlock context during restricted pointer formatting Thomas Weißschuh
4 siblings, 0 replies; 8+ messages in thread
From: Thomas Weißschuh @ 2026-06-08 14:21 UTC (permalink / raw)
To: Andrew Morton, Petr Mladek, Steven Rostedt, Andy Shevchenko,
Rasmus Villemoes, Sergey Senozhatsky, Peter Zijlstra, Ingo Molnar,
Will Deacon, Boqun Feng, Waiman Long, Sebastian Andrzej Siewior,
Clark Williams, Kees Cook
Cc: linux-kernel, linux-rt-devel, Thomas Weißschuh
When kptr_restrict is set to '1' restricted pointers can only be used
in task context. As kptr_restrict can change at any time at runtime,
this means that restricted pointers can only be used from task context
in general.
Add an assertion to detect misuse early, independently of the
current runtime configuration.
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
---
lib/vsprintf.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 6095b5f0d022..09e0e5194d41 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -29,6 +29,7 @@
#include <linux/hex.h>
#include <linux/kernel.h>
#include <linux/kallsyms.h>
+#include <linux/lockdep.h>
#include <linux/math64.h>
#include <linux/uaccess.h>
#include <linux/ioport.h>
@@ -863,6 +864,8 @@ static noinline_for_stack
char *restricted_pointer(char *buf, char *end, const void *ptr,
struct printf_spec spec)
{
+ lockdep_assert(in_task());
+
switch (kptr_restrict) {
case 0:
/* Handle as %p, hash and do _not_ leak addresses. */
--
2.54.0
^ permalink raw reply related [flat|nested] 8+ messages in thread* [PATCH v4 5/5] lib/vsprintf: Validate spinlock context during restricted pointer formatting
2026-06-08 14:21 [PATCH v4 0/5] lib/vsprintf: Validate spinlock context during restricted pointer formatting Thomas Weißschuh
` (3 preceding siblings ...)
2026-06-08 14:21 ` [PATCH v4 4/5] lib/vsprintf: Always check interrupt context restrictions Thomas Weißschuh
@ 2026-06-08 14:21 ` Thomas Weißschuh
2026-06-11 10:09 ` Thomas Weißschuh
4 siblings, 1 reply; 8+ messages in thread
From: Thomas Weißschuh @ 2026-06-08 14:21 UTC (permalink / raw)
To: Andrew Morton, Petr Mladek, Steven Rostedt, Andy Shevchenko,
Rasmus Villemoes, Sergey Senozhatsky, Peter Zijlstra, Ingo Molnar,
Will Deacon, Boqun Feng, Waiman Long, Sebastian Andrzej Siewior,
Clark Williams, Kees Cook
Cc: linux-kernel, linux-rt-devel, Thomas Weißschuh
Depending on the system configuration, the restricted pointer formatting
might call into the security subsystem which takes spinlocks, which
might sleep under PREEMPT_RT. As %pK is intended to be only used from
read handlers of virtual files, which always run in task context,
this should not be a problem in practice.
However, developers have used %pK before from atomic context without
realizing this restriction. While all existing user of %pK through
printk() have been removed, new ones might be reintroduced accidentally
in the future.
Add a lockdep annotation to unconditionally introduce a fake spinlock in
restricted_pointer(), so lockdep can detect misuse even if the current
test system configuration would not exhibit the issue.
This is intentionally a single lock instance shared by all callers,
as that mirrors what can happen in the security subsystem.
This check comes intentionally after the in_task() one, to have the
clearer diagnostic first when the function is called from IRQ context,
which will trigger both.
Link: https://lore.kernel.org/lkml/20250113171731-dc10e3c1-da64-4af0-b767-7c7070468023@linutronix.de/
Link: https://lore.kernel.org/lkml/20241217142032.55793-1-acarmina@redhat.com/
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Reviewed-by: Petr Mladek <pmladek@suse.com>
---
lib/vsprintf.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 09e0e5194d41..728a1acd69ae 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -864,7 +864,14 @@ static noinline_for_stack
char *restricted_pointer(char *buf, char *end, const void *ptr,
struct printf_spec spec)
{
+ /*
+ * has_capability_noaudit() may use spinlocks.
+ * Make sure %pK is only used from valid contexts.
+ */
+ static DEFINE_WAIT_ASSERT_MAP(vsprintf_restricted_pointer_map, LD_WAIT_CONFIG);
+
lockdep_assert(in_task());
+ guard(lock_map_acquire)(&vsprintf_restricted_pointer_map);
switch (kptr_restrict) {
case 0:
--
2.54.0
^ permalink raw reply related [flat|nested] 8+ messages in thread* Re: [PATCH v4 5/5] lib/vsprintf: Validate spinlock context during restricted pointer formatting
2026-06-08 14:21 ` [PATCH v4 5/5] lib/vsprintf: Validate spinlock context during restricted pointer formatting Thomas Weißschuh
@ 2026-06-11 10:09 ` Thomas Weißschuh
2026-06-16 9:14 ` Petr Mladek
0 siblings, 1 reply; 8+ messages in thread
From: Thomas Weißschuh @ 2026-06-11 10:09 UTC (permalink / raw)
To: Andrew Morton, Petr Mladek, Steven Rostedt, Andy Shevchenko,
Rasmus Villemoes, Sergey Senozhatsky, Peter Zijlstra, Ingo Molnar,
Will Deacon, Boqun Feng, Waiman Long, Sebastian Andrzej Siewior,
Clark Williams, Kees Cook
Cc: linux-kernel, linux-rt-devel
On Mon, Jun 08, 2026 at 04:21:45PM +0200, Thomas Weißschuh wrote:
> Depending on the system configuration, the restricted pointer formatting
> might call into the security subsystem which takes spinlocks, which
> might sleep under PREEMPT_RT. As %pK is intended to be only used from
> read handlers of virtual files, which always run in task context,
> this should not be a problem in practice.
> However, developers have used %pK before from atomic context without
> realizing this restriction. While all existing user of %pK through
> printk() have been removed, new ones might be reintroduced accidentally
> in the future.
>
> Add a lockdep annotation to unconditionally introduce a fake spinlock in
> restricted_pointer(), so lockdep can detect misuse even if the current
> test system configuration would not exhibit the issue.
> This is intentionally a single lock instance shared by all callers,
> as that mirrors what can happen in the security subsystem.
>
> This check comes intentionally after the in_task() one, to have the
> clearer diagnostic first when the function is called from IRQ context,
> which will trigger both.
>
> Link: https://lore.kernel.org/lkml/20250113171731-dc10e3c1-da64-4af0-b767-7c7070468023@linutronix.de/
> Link: https://lore.kernel.org/lkml/20241217142032.55793-1-acarmina@redhat.com/
> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> Reviewed-by: Petr Mladek <pmladek@suse.com>
> ---
> lib/vsprintf.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> index 09e0e5194d41..728a1acd69ae 100644
> --- a/lib/vsprintf.c
> +++ b/lib/vsprintf.c
> @@ -864,7 +864,14 @@ static noinline_for_stack
> char *restricted_pointer(char *buf, char *end, const void *ptr,
> struct printf_spec spec)
> {
> + /*
> + * has_capability_noaudit() may use spinlocks.
> + * Make sure %pK is only used from valid contexts.
> + */
> + static DEFINE_WAIT_ASSERT_MAP(vsprintf_restricted_pointer_map, LD_WAIT_CONFIG);
> +
> lockdep_assert(in_task());
> + guard(lock_map_acquire)(&vsprintf_restricted_pointer_map);
The kernel test robot found a lockdep violation with this patch:
https://lore.kernel.org/all/202606110945.d3871219-lkp@intel.com/
My suspicion is that this is a pre-existing problem that was not visible
to lockdep so far, exactly what this patch is supposed to mitigate.
I'll investigate some more and try to reproduce it.
> switch (kptr_restrict) {
> case 0:
>
> --
> 2.54.0
>
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [PATCH v4 5/5] lib/vsprintf: Validate spinlock context during restricted pointer formatting
2026-06-11 10:09 ` Thomas Weißschuh
@ 2026-06-16 9:14 ` Petr Mladek
0 siblings, 0 replies; 8+ messages in thread
From: Petr Mladek @ 2026-06-16 9:14 UTC (permalink / raw)
To: Thomas Weißschuh
Cc: Andrew Morton, Steven Rostedt, Andy Shevchenko, Rasmus Villemoes,
Sergey Senozhatsky, Peter Zijlstra, Ingo Molnar, Will Deacon,
Boqun Feng, Waiman Long, Sebastian Andrzej Siewior,
Clark Williams, Kees Cook, linux-kernel, linux-rt-devel
On Thu 2026-06-11 12:09:08, Thomas Weißschuh wrote:
> On Mon, Jun 08, 2026 at 04:21:45PM +0200, Thomas Weißschuh wrote:
> > Depending on the system configuration, the restricted pointer formatting
> > might call into the security subsystem which takes spinlocks, which
> > might sleep under PREEMPT_RT. As %pK is intended to be only used from
> > read handlers of virtual files, which always run in task context,
> > this should not be a problem in practice.
> > However, developers have used %pK before from atomic context without
> > realizing this restriction. While all existing user of %pK through
> > printk() have been removed, new ones might be reintroduced accidentally
> > in the future.
> >
> > Add a lockdep annotation to unconditionally introduce a fake spinlock in
> > restricted_pointer(), so lockdep can detect misuse even if the current
> > test system configuration would not exhibit the issue.
> > This is intentionally a single lock instance shared by all callers,
> > as that mirrors what can happen in the security subsystem.
> >
> > This check comes intentionally after the in_task() one, to have the
> > clearer diagnostic first when the function is called from IRQ context,
> > which will trigger both.
> >
> > Link: https://lore.kernel.org/lkml/20250113171731-dc10e3c1-da64-4af0-b767-7c7070468023@linutronix.de/
> > Link: https://lore.kernel.org/lkml/20241217142032.55793-1-acarmina@redhat.com/
> > Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> > Reviewed-by: Petr Mladek <pmladek@suse.com>
> > ---
> > lib/vsprintf.c | 7 +++++++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> > index 09e0e5194d41..728a1acd69ae 100644
> > --- a/lib/vsprintf.c
> > +++ b/lib/vsprintf.c
> > @@ -864,7 +864,14 @@ static noinline_for_stack
> > char *restricted_pointer(char *buf, char *end, const void *ptr,
> > struct printf_spec spec)
> > {
> > + /*
> > + * has_capability_noaudit() may use spinlocks.
> > + * Make sure %pK is only used from valid contexts.
> > + */
> > + static DEFINE_WAIT_ASSERT_MAP(vsprintf_restricted_pointer_map, LD_WAIT_CONFIG);
> > +
> > lockdep_assert(in_task());
> > + guard(lock_map_acquire)(&vsprintf_restricted_pointer_map);
>
> The kernel test robot found a lockdep violation with this patch:
> https://lore.kernel.org/all/202606110945.d3871219-lkp@intel.com/
>
> My suspicion is that this is a pre-existing problem that was not visible
> to lockdep so far, exactly what this patch is supposed to mitigate.
> I'll investigate some more and try to reproduce it.
I was curious and found the following. The problematic patch seems to be:
[ 92.754552][ T3827] lock_acquire (locking/lockdep.c:5868)
[ 92.757345][ T3827] class_lock_map_acquire_constructor (linux/lockdep.h:557 (discriminator 1))
[ 92.759895][ T3827] restricted_pointer (vsprintf.c:874)
[ 92.770231][ T3827] pointer (vsprintf.c:2582)
[ 92.772166][ T3827] vsnprintf (vsprintf.c:2956)
[ 92.774145][ T3827] seq_printf (seq_file.c:392 seq_file.c:407)
[ 92.776083][ T3827] tcp6_seq_show (ipv6/tcp_ipv6.c:2147 (discriminator 1) ipv6/tcp_ipv6.c:2221 (discriminator 1))
[ 92.778212][ T3827] traverse (seq_file.c:112)
[ 92.780125][ T3827] seq_lseek (seq_file.c:324 (discriminator 1))
[ 92.782106][ T3827] proc_reg_llseek (proc/inode.c:283)
[ 92.789616][ T3827] __ia32_sys_lseek (read_write.c:391)
[ 92.791786][ T3827] ia32_sys_call (kbuild/obj/consumer/i386-randconfig-013-20260610/./arch/x86/include/generated/asm/syscalls_32.h:20)
[ 92.793792][ T3827] __do_fast_syscall_32 (x86/entry/syscall_32.c:83)
[ 92.795973][ T3827] do_fast_syscall_32 (x86/entry/syscall_32.c:332)
[ 92.797992][ T3827] do_SYSENTER_32 (x86/entry/syscall_32.c:370)
[ 92.799987][ T3827] entry_SYSENTER_32 (x86/entry/entry_32.S:835)
If I get it correctly then traverse() might take spin_lock_bh(lock)
via:
+ traverse()
+ tcp_seq_start()
+ tcp_get_idx()
+ established_get_idx()
+ established_get_first()
+ spin_lock_bh(lock);
And then it calls vsnprintf(" %pK" in
+ tcp6_seq_show()
+ get_tcp6_sock()
+ seq_printf()
By other words, it calls vsnprintf("%pK") with disabled softirqs.
If I get it correctly then this might create a deadlock because
vsnprinf("%pK") can be called also with (soft)irqs enabled,
then soft(irq) might came and want to take the spin_lock(lock)...
As a result, we should not use %pK in tcp6_seq_show().
Best Regards,
Petr
^ permalink raw reply [flat|nested] 8+ messages in thread