On 2019-03-04, Sergey Senozhatsky <sergey.senozhatsky.work@xxxxxxxxx> wrote: >>>> - A dedicated kernel thread is created for printing to all consoles >>>> in a fully preemptible context. >>> >>> How do you handle sysrq-<foo> printouts on systems which can't >>> schedule printk-kthread? >> >> If those sysrq printouts are at the emergency loglevel (which most >> are), then they are printed immediately to the emergency >> consoles. This has already proved useful for our own kernel debugging >> work. For example, currently sysrq-z for very large traces result in >> messages being dropped because of printk buffer overflows. But with >> the emergency console we always see the full trace buffer. > > Are we sure that all systems will always have ->atomic console(-s) > enabled? Is it possible to convert all console drivers to ->atomic? > fbcon, for instance (with scrolling and font scaling, etc)? No, I am not sure if we can convert all console drivers to atomic consoles. But I think if we don't have to fear disturbing the system, the possibilities for such an implementation are greater. > If there are setups which can be fully !atomic (in terms of console > output) then we, essentially, have a fully preemptible kthread printk > implementation. Correct. I've mentioned in another response[0] some ideas about what could be done to aid this. I understand that fully preemptible kthread printing is unacceptable for you. Since all current console drivers are already irq safe, I'm wondering if using irq_work to handle the emergency printing for console drivers without write_atomic() would help. (If the printk caller is in a context that write() supports, then write() could be called directly.) This would also demand that the irq-safe requirements for write() are not relaxed. The printk-kthread might still be faster than irq_work, but it might increase reliability if an irq_work is triggered as an extra precaution. John Ogness [0] https://lkml.kernel.org/r/87o96p9gtx.fsf@xxxxxxxxxxxxx
