Re: deadlock caused by printk

[Peter Zijlstra <peterz@infradead.org>]

On Fri, 2011-03-25 at 13:21 +0100, Peter Zijlstra wrote:
> On Fri, 2011-03-25 at 20:15 +0800, Ming Lei wrote:
> > Hi,
> > 
> > These days I was studying "perf code" and try to dump some debug
> > info in event_sched_out(): kernel/perf_event.c by printk, but found
> > system can hang easily.
> > 
> > After digging into related code for several days, I find the hang is
> > caused by spinlock deadlock when acquiring rq->lock in task_rq_lock(),
> > which is called in the path below:
> > 
> >           try_to_wake_up<-wake_up_process<-up<-console_unlock<-printk.
> > 
> > I wonder if there are some usage conventions about printk, which says
> > explicitly that printk can not by used in some places of kernel. Or does the
> > above show that it is a bug of kernel?
> > 
> > If the above is really a limitation of printk, have we other dump functions
> > which may be used safely in some places of kernel source code where
> > printk is not allowed.
> 
> Don't use printk from NMI context, that's never going to work well.

OK, so I probably should shut down the computer and go back to being
ill, the thing you mentioned isn't in fact NMI context, but yeah using
it from inside the scheduler isn't going to be fun either.

> One thing you could to is use trace_printk() and use ftrace to debug
> perf.

That should still work.