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

[Petr Mladek <pmladek@suse.com>]

On Fri 2026-06-26 19:06:58, Sebastian Andrzej Siewior wrote:
> 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.

I am all for removing the restricted pointers stuff. IMHO, it has been
obsoleted by the generic hashing but it has never been officially
mentioned anywhere.

I hope that networking guys would take it.

Best Regards,
Petr