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

[Petr Mladek <pmladek@suse.com>]

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