On Wed 2019-03-13 18:27:59, Sergey Senozhatsky wrote: > On (03/13/19 09:40), Sebastian Siewior wrote: > > On 2019-03-13 09:19:32 [+0100], John Ogness wrote: > > > recursive situation. As you are pointing out, the notification/wake > > > component of printk_safe will still be needed. I will leave that (small) > > > part in printk_safe.c. > > > > Does this mean we keep irq_work part or we bury it and solve it by other > > means? > > *May be* we can take a closer look and find cases when ->atomic > consoles don't really depend on console_sem. And *may be* we can > split the console drivers list and somehow forbid removal and > modification (ioctl) of ->atomic consoles under us. Assuming that > this is doable we then can start iterating ->atomic consoles list > with unlocked console_sem. I believe that this is actually the plan. Atomic consoles depending on console_sem would not be a real step forward. > Non->atomic consoles or consoles which depend on console_sem (VT, > fbcon and so on) will stay in another list, and we will take > console_sem before we iterate that list and invoke those drivers. This might be also needed for "less" important messages that people would not want to get to the console atomically because it would serialize CPUs and slow down the entire system. I think that we would still need irq_work for this mode. But it should be necessary only for messages from NMI context and printk() recursion. It means that it should be a rare situation and the amount of messages should get limited. It should not be much worse than handling few printk() calls from any irq handler. Best Regards, Petr
