Re: [RFC][PATCHv6 00/12] printk: introduce printing kernel thread

[Petr Mladek]

On Mon 2017-12-18 22:39:48, Sergey Senozhatsky wrote:
> On (12/18/17 14:31), Petr Mladek wrote:
> > On Mon 2017-12-18 18:36:15, Sergey Senozhatsky wrote:
> > > On (12/15/17 10:08), Petr Mladek wrote:
> > > 1) it opens both soft and hard lockup vectors
> > > 
> > >    I see *a lot* of cases when CPU that call printk in a loop does not
> > >    end up flushing its messages. And the problem seems to be - preemption.
> > > 
> > > 
> > >   CPU0						CPU1
> > > 
> > >   for_each_process_thread(g, p)
> > >     printk()
> > 
> > You print one message for each process in a tight loop.
> > Is there a code like this?
> 
> um... show_state() -> show_state_filter()?
> which prints million times more info than a single line per-PID.

Good example. Heh, it already somehow deals with this:

void show_state_filter(unsigned long state_filter)
{
	struct task_struct *g, *p;

	rcu_read_lock();
	for_each_process_thread(g, p) {
		/*
		 * reset the NMI-timeout, listing all files on a slow
		 * console might take a lot of time:
		 * Also, reset softlockup watchdogs on all CPUs, because
		 * another CPU might be blocked waiting for us to process
		 * an IPI.
		 */
		touch_nmi_watchdog();
		touch_all_softlockup_watchdogs();
		if (state_filter_match(state_filter, p))
			sched_show_task(p);


One question is if we really want to rely on offloading in
this case. What if this is printed to debug some stalled
system.

Best Regards,
Petr