Messages in this thread | | | Date | Tue, 19 Dec 2017 13:36:58 +0900 | From | Sergey Senozhatsky <> | Subject | Re: [RFC][PATCHv6 00/12] printk: introduce printing kernel thread |
| |
On (12/18/17 12:46), Steven Rostedt wrote: > > One question is if we really want to rely on offloading in > > this case. What if this is printed to debug some stalled > > system. > > Correct, and this is what I call when debugging hard lockups, and I do > it from NMI. [..] > show_state_filter() is not a normal printk() call. It is used for > debugging.
just for the record. a side note.
you guys somehow made spectacularly off-target conclusions from the traces I have provided and decided NOT to concentrate on demonstrated behavioural patterns, but on, perhaps, process' names (I really should have renamed i_do_printks to DONALD_TRUMP ;) ) and on how those printk lines got into the logbuf. like if it mattered. [seriously, why?]. the point was not in show_state_filter()... the point was - preemption and things that hand off does. but somehow filling up logbuf when console_sem owner is preempted is unrealistic if printks are coming from task A under normal conditions; and it is a completely different story when the same task A fills up logbuf from OOM while console_sem owner is preempted. the end result is the same in both cases: it's not task A that is going to flush logbuf. it's some other task that will have to do it, possibly being in atomic context. anyway, anyway.
-ss
| |