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

From: Petr Mladek

Date: Fri Jun 26 2026 - 11:58:47 EST


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

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