Re: [BUG] perf: hard lockup when using perf-sched

[Frederic Weisbecker <fweisbec@gmail.com>]

On Fri, Mar 26, 2010 at 11:11:33AM +0100, Mike Galbraith wrote:
> On Thu, 2010-03-25 at 10:27 +0100, Mike Galbraith wrote:
> > On Thu, 2010-03-25 at 16:04 +0800, Li Zefan wrote:
> > > Mike Galbraith wrote:
> > > > On Wed, 2010-03-24 at 08:32 +0100, Mike Galbraith wrote:
> > > > 
> > > >> I just saw this, hunted down your testcase and tried it here.  Looks
> > > >> like perf_output_lock() wedged box.
> > > > 
> > > > (turns on frame pointers, and adds noinline)
> > > > 
> > > 
> > > Thanks! Then who's going to fix this...
> > 
> > Well, that kinda depends on whether I figure out how the heck it's all
> > supposed to work before somebody else whacks it or not.
> 
> This seems to work, in contrast to everything I tried yesterday.  Not
> exactly a thing of beauty, but at least it's an option, so...
> 
> perf: fix perf sched record forkbomb deadlock
> 
> perf sched record can deadlock a box should the holder of handle->data->lock
> take an interrupt, and then attempt to acquire an rq lock held by a CPU trying
> to acquire the same lock.  Disable interrupts.



Aah.

So the scenario is the following inversion?

	CPU0				CPU1
sched event with rq->lock held
				grab handle->data->lock
spin on handle->data->lock
				interrupt
				try to grab rq->lock