[PATCH v4 0/5] lib/vsprintf: Validate spinlock context during restricted pointer formatting

[PATCH v4 0/5] lib/vsprintf: Validate spinlock context during restricted pointer formatting

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

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.

---
Changes in v4:
- Pick up review from Petr.
- Check in_task() before LD_WAIT_CONFIG.
- Make commit message slightly clearer.
- Reorder patches to avoid problematic temporary states.
- Link to v3: https://patch.msgid.link/20260520-restricted-pointers-final-v3-0-76bca6a6ab3f@linutronix.de

Changes in v3:
- Use in_task() over its open-coded inverse.
  - Also switch the existing check over to it.
- Link to v2: https://patch.msgid.link/20260504-restricted-pointers-final-v2-0-4934933503e5@linutronix.de

Changes in v2:
- Use custom lock_map over might_sleep()
- Also assert IRQ context
- Link to v1: https://lore.kernel.org/r/20260317-restricted-pointers-final-v1-1-b4dca0ed6483@linutronix.de

To: Andrew Morton <akpm@linux-foundation.org>
To: Petr Mladek <pmladek@suse.com>
To: Steven Rostedt <rostedt@goodmis.org>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Rasmus Villemoes <linux@rasmusvillemoes.dk>
To: Sergey Senozhatsky <senozhatsky@chromium.org>
To: Peter Zijlstra <peterz@infradead.org>
To: Ingo Molnar <mingo@redhat.com>
To: Will Deacon <will@kernel.org>
To: Boqun Feng <boqun@kernel.org>
To: Waiman Long <longman@redhat.com>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: Clark Williams <clrkwllms@kernel.org>
To: Kees Cook <kees@kernel.org>
Cc: linux-kernel@vger.kernel.org
Cc: linux-rt-devel@lists.linux.dev
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>

---
Thomas Weißschuh (5):
      locking/lockdep: Add a helper to validate the locking context without a lock
      locking/lockdep: Add a guard for lock_map_acquire()
      lib/vsprintf: Use in_task() for restricted pointer context check
      lib/vsprintf: Always check interrupt context restrictions
      lib/vsprintf: Validate spinlock context during restricted pointer formatting

 include/linux/lockdep.h | 11 +++++++++++
 lib/vsprintf.c          | 12 +++++++++++-
 2 files changed, 22 insertions(+), 1 deletion(-)
---
base-commit: d870b998ed2e4184cbe312f4a4e2fd60d1360caf
change-id: 20260107-restricted-pointers-final-cd24979fd752

Best regards,
--  
Thomas Weißschuh <thomas.weissschuh@linutronix.de>

[PATCH v4 1/5] locking/lockdep: Add a helper to validate the locking context without a lock

[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

[PATCH v4 2/5] locking/lockdep: Add a guard for lock_map_acquire()

[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

[PATCH v4 3/5] lib/vsprintf: Use in_task() for restricted pointer context check

[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

[PATCH v4 4/5] lib/vsprintf: Always check interrupt context restrictions

[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

[PATCH v4 5/5] lib/vsprintf: Validate spinlock context during restricted pointer formatting

[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

Re: [PATCH v4 5/5] lib/vsprintf: Validate spinlock context during restricted pointer formatting

[Thomas Weißschuh]

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
> 

Re: [PATCH v4 5/5] lib/vsprintf: Validate spinlock context during restricted pointer formatting

[Petr Mladek]

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

Re: [PATCH v4 5/5] lib/vsprintf: Validate spinlock context during restricted pointer formatting

[Sebastian Andrzej Siewior]

On 2026-06-11 12:09:08 [+0200], Thomas Weißschuh wrote:
> > @@ -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.

The annotation is "wrong". What you say "I do spin_lock() here".
Then lockdep figured out that this lock is acquired under a lock which
is used also from within softirq. This in turn can lead to a dependency
problem based on softirq:

|       CPU0                    CPU1
|       ----                    ----
|  lock(vsprintf_restricted_pointer_map-wait-type-assert);
|                               local_irq_disable();
|                               lock(&ptr[i]);
|                               lock(vsprintf_restricted_pointer_map-wait-type-assert);
|  <Interrupt>
|    lock(&ptr[i]);
| 
| *** DEADLOCK ***

If I'm not mistaken then this will not happen in real life because the
hook callback does _always_ spin_lock_irqsave() and as such it avoids
the interrupt+lock on CPU0 in this example.

Sebastian

Re: [PATCH v4 5/5] lib/vsprintf: Validate spinlock context during restricted pointer formatting

[Petr Mladek]

On Thu 2026-06-25 16:51:15, Sebastian Andrzej Siewior wrote:
> On 2026-06-11 12:09:08 [+0200], Thomas Weißschuh wrote:
> > > @@ -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.
> 
> The annotation is "wrong". What you say "I do spin_lock() here".
> Then lockdep figured out that this lock is acquired under a lock which
> is used also from within softirq. This in turn can lead to a dependency
> problem based on softirq:
> 
> |       CPU0                    CPU1
> |       ----                    ----
> |  lock(vsprintf_restricted_pointer_map-wait-type-assert);
> |                               local_irq_disable();
> |                               lock(&ptr[i]);
> |                               lock(vsprintf_restricted_pointer_map-wait-type-assert);
> |  <Interrupt>
> |    lock(&ptr[i]);
> | 
> | *** DEADLOCK ***
> 
> If I'm not mistaken then this will not happen in real life because the
> hook callback does _always_ spin_lock_irqsave() and as such it avoids
> the interrupt+lock on CPU0 in this example.

Interesting, does the spin_lock_irqsave() even allow sleeping under RT?

I mean, does spin_lock_irqsave() violate the raw_spin_lock
vs. spin_lock nesting rules?

Best Regards,
Petr

Re: [PATCH v4 5/5] lib/vsprintf: Validate spinlock context during restricted pointer formatting

[Petr Mladek]

On Fri 2026-06-26 17:53:27, Petr Mladek wrote:
> On Thu 2026-06-25 16:51:15, Sebastian Andrzej Siewior wrote:
> > On 2026-06-11 12:09:08 [+0200], Thomas Weißschuh wrote:
> > > > @@ -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.
> > 
> > The annotation is "wrong". What you say "I do spin_lock() here".
> > Then lockdep figured out that this lock is acquired under a lock which
> > is used also from within softirq. This in turn can lead to a dependency
> > problem based on softirq:
> > 
> > |       CPU0                    CPU1
> > |       ----                    ----
> > |  lock(vsprintf_restricted_pointer_map-wait-type-assert);
> > |                               local_irq_disable();
> > |                               lock(&ptr[i]);
> > |                               lock(vsprintf_restricted_pointer_map-wait-type-assert);
> > |  <Interrupt>
> > |    lock(&ptr[i]);
> > | 
> > | *** DEADLOCK ***
> > 
> > If I'm not mistaken then this will not happen in real life because the
> > hook callback does _always_ spin_lock_irqsave() and as such it avoids
> > the interrupt+lock on CPU0 in this example.
> 
> Interesting, does the spin_lock_irqsave() even allow sleeping under RT?
> 
> I mean, does spin_lock_irqsave() violate the raw_spin_lock
> vs. spin_lock nesting rules?

Ignore the silly question, please. Sure, even spin_lock_irqsafe()
is a sleeping lock in RT.

That said, I am not sure how to effectively pretend the right
context to lockdep. It looks a bit ugly to disable interrupts
around all the code which is guarded only by a fake lock_map.

Best Regards,
Petr

PS: I am sorry for the rummour. It is Friday evening and a very hot
    weather here.

Re: [PATCH v4 5/5] lib/vsprintf: Validate spinlock context during restricted pointer formatting

[Sebastian Andrzej Siewior]

On 2026-06-26 18:06:09 [+0200], Petr Mladek wrote:
> > Interesting, does the spin_lock_irqsave() even allow sleeping under RT?
> > 
> > I mean, does spin_lock_irqsave() violate the raw_spin_lock
> > vs. spin_lock nesting rules?
> 
> Ignore the silly question, please. Sure, even spin_lock_irqsafe()
> is a sleeping lock in RT.
> 
> That said, I am not sure how to effectively pretend the right
> context to lockdep. It looks a bit ugly to disable interrupts
> around all the code which is guarded only by a fake lock_map.

That splat is from !RT and here it wouldn't happen if interrupts were
disabled.
On RT that interrupt (softirq) would not interrupt as such. So it is not
possible due to how softirqs are processed.

My idea is to remove that thing so we don't have to annotate it.
The reason behind it: There is no added benefit from my point of view.
I can't think of reason to return real kernel pointers via proc/ sysfs
to the user which depend on a security policy. The %p will return a
value which can be compared against other values and check if it is the
same or not. The root user or dev can either disable this hashing
behaviour or use %px while debugging. I haven't figured a reason why
this is important.

If you have something, I am all yours. If not, I poke networking next
week and try to remove this entirely.

> Best Regards,
> Petr
> 
> PS: I am sorry for the rummour. It is Friday evening and a very hot
>     weather here.

I tried to stay strong but in the end I relocated towards the basement
and continued working there.

Sebastian