[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1295617185.28776.273.camel@laptop>
Date: Fri, 21 Jan 2011 14:39:45 +0100
From: Peter Zijlstra <a.p.zijlstra@...llo.nl>
To: Ingo Molnar <mingo@...e.hu>
Cc: Oleg Nesterov <oleg@...hat.com>,
Alan Stern <stern@...land.harvard.edu>,
Arnaldo Carvalho de Melo <acme@...hat.com>,
Frederic Weisbecker <fweisbec@...il.com>,
Paul Mackerras <paulus@...ba.org>,
Prasad <prasad@...ux.vnet.ibm.com>,
Roland McGrath <roland@...hat.com>,
linux-kernel@...r.kernel.org
Subject: Re: Q: perf_install_in_context/perf_event_enable are racy?
On Fri, 2011-01-21 at 14:03 +0100, Ingo Molnar wrote:
> > > But, it seems, there is another problem. Forget about the exiting,
> > > I can't understand why we can trust current in the code above.
> > > With __ARCH_WANT_INTERRUPTS_ON_CTXSW schedule() does:
> > >
> > > // sets cpuctx->task_ctx = NULL
> > > perf_event_task_sched_out();
> > >
> > > // enables irqs
> > > prepare_lock_switch();
> > >
> > >
> > > // updates current_task
> > > switch_to();
> > >
> > > What if IPI comes in the window before switch_to() ?
> > >
> > > (the same questions for __perf_event_enable).
> >
> > Ingo, do you have any insights in that, I think you wrote all that
> > initially?
>
> Not sure. Can an IPI come there - we have irqs disabled usually, dont we?
Ah, I think I see how that works:
__perf_event_task_sched_out()
perf_event_context_sched_out()
if (do_switch)
cpuctx->task_ctx = NULL;
vs
__perf_install_in_context()
if (cpu_ctx->task_ctx != ctx)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists