On Wed 2024-12-18 15:13:13, John Ogness wrote: > On 2024-12-18, Petr Mladek <pmladek@xxxxxxxx> wrote: > > My concern is taking a lock when processing a printf format, see > > below for more details. > > Your concern is valid! printk() uses vsnprintf() to format records for > the kernel log. printk() may be called from contexts where locking is > forbidden (such as NMI). If vsnprintf() can take a lock, then either: > > vsnprintf() must be made to be lockless > > or > > printk() must take another approach to string formatting There were the ideas to introduce a %pX[1] or %pf[2] formats. They would allow to pass pointer to a custom callback and parameters which then would be used by vsprintf(). This might allow to make it more obvious that the given vsprintf()/printk() might do some locking. > or > > we accept that printk() can deadlock for certain format types in certain > contexts. I see that %pOFm does not add any new locking dependency. The same lock (devtree_lock) is already taken, for example, by %pOFC format. I do not want to revert everything now just because of theoretical problems. It somehow works because people use these formats only in dedicated subsystems. Also lockdep is able to catch a lot of problems. Well, it would be nice to document the lock dependency in Documentation/core-api/printk-formats.rst Best Regards, Petr
