Re: [PATCH] printk: robustify printk

[Ingo Molnar <mingo@elte.hu>]

* Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:

> On Fri, 2008-08-08 at 21:21 +0200, Peter Zijlstra wrote:
> 
> > The initial printk_tick() based implementation didn't suffer this
> > problem, should we revert to that scheme?
> 
> Just in case people care..
> 
> ---
> Subject: printk: robustify printk
> 
> Avoid deadlocks against rq->lock and xtime_lock by deferring the klogd 
> wakeup by polling from the timer tick.

i missed most of the discussion, but this seems like the simplest (and 
hence ultimately the best) approach to me.

Coupling printk with RCU, albeit elegant, does not seem like the right 
choice to me in this specific case: printk as an essential debug 
mechanism should be as decoupled as possible.

Also, once we accept the possibility of async klogd completion, we might 
as well do it all the time.

i have only one sidenote:

> --- linux-2.6.orig/kernel/time/tick-sched.c
> +++ linux-2.6/kernel/time/tick-sched.c
> @@ -255,7 +255,7 @@ void tick_nohz_stop_sched_tick(int inidl
>       next_jiffies = get_next_timer_interrupt(last_jiffies);
>       delta_jiffies = next_jiffies - last_jiffies;
>
> -     if (rcu_needs_cpu(cpu))
> +     if (rcu_needs_cpu(cpu) || printk_needs_cpu(cpu))
>               delta_jiffies = 1;

this change made a previous design quirks even more visible: these are 
items that are not purely event driven but need some polling component. 
RCU is one, and now printk is another.

We could clean this up further by integrating the rcu_needs_cpu() and 
printk_needs_cpu() into a softirq mechanism. We already check for 
pending softirqs in tick-sched.c, so the above complication would go 
away completely.

( But that's for a separate cleanup patch i think. )

No strong feelings though. Peter, which one do you prefer?

	Ingo