Re: lock in vsprintf(): was: Re: [PATCH] of: Add printf '%pOFm' for generating modalias
From: Rob Herring
Date: Mon Dec 30 2024 - 15:26:57 EST
On Thu, Dec 19, 2024 at 08:17:21PM +0106, John Ogness wrote:
> On 2024-12-19, Petr Mladek <pmladek@xxxxxxxx> wrote:
> > I do not want to revert everything now just because of theoretical
> > problems.
>
> What would you revert? This has always been an issue for printk().
>
> > Well, it would be nice to document the lock dependency in
> > Documentation/core-api/printk-formats.rst
>
> Yes. If any locking is involved at all, such specifiers should be
> documented as not safe in NMI context or within printk_cpu_sync
> blocks.
For the folks that don't read documentation, should we bail out on
in_nmi() for these as well?
> Also, it should be checked if all such locks are
> raw_spinlock_t. If any other lock type is used, it probably is already
> generating a lockdep splat since printk() formats records with local
> interrupts off.
At least for DT, that is the case. There is a mutex, but that's only
taken if the tree is modified.
> Perhaps we should create a kunit that calls printk() for each of the
> supported specifiers and see if any lockdep splats appear.
That's already in place with the DT unit test (which doesn't use kunit
ATM).
Rob