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
