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@xxxxxxxxx/
> 
> 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