Messages in this thread |  | | Date | Fri, 12 Jan 2018 12:12:40 +0900 | From | Sergey Senozhatsky <> | Subject | Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup |
| |
On (01/11/18 20:30), Steven Rostedt wrote: [..] > Today, printk() can print for a time of A * B, where, as you state > above: > > A is the amount of data to print in the worst case > B the time call_console_drivers() needs to print a single > char to all registered and enabled consoles > > In the worse case, the current approach is A is infinite. That is, > printk() never stops, as long as there is a printk happening on another > CPU before B can finish. A will keep growing. The call to printk() will > never return. The more CPUs you have, the more likely this will occur. > All it takes is a few CPUs doing periodic printks. If there is a slow > console, where the periodic printk on other CPUs occur quicker than the > first can finish, the first one will be stuck forever. Doesn't take > much to have this happen.
console_sem owner can stuck in console_unlock() not because of printk-s happening right now on other CPUs, but because those printk-s could have happened while console_sem owner was preempted. when it comes back it has a ton of pending messages.
I said it before - "we stuck in console_unlock() because others CPUs printk right now a lot" is not always true. we have preemption. and the "last console_sem owner prints it all" is not good in this case.
> With my patch, A is fixed to the size of the buffer. A single printk() > can never print more than that. If another CPU comes in and does a > printk, then it will take over the task of printing, and release the > first printk.
yes. and "another CPU" that comes to take over has to print all the pending messages. from whatever context it's currently in. and bringing A * B below C can be quite tricky, if possible at all (!). most likely people will just add more touch_nmi_watchdog().
again, I don't disagree on "let's bound printk". yes, we totally should! but the bound must be realistic if we want to fix the damn thing (either with printk_kthread, or hand off, or anything else).
-ss
|  |