[lkml]   [2018]   [Jan]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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).


 \ /
  Last update: 2018-01-14 23:25    [W:0.200 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site