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

[Petr Mladek <pmladek@suse.com>]

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.