On 11/15/2011 03:38 PM, Steven Rostedt wrote: > On Tue, 2011-11-15 at 15:01 +0200, Avi Kivity wrote: > > Stop tracing when we read the clock, since tracing will also > > want to read the clock, and recurse indefinitely. > > I would rephrase the above. You don't actually stop tracing, you just > don't trace the preempt disable. I would reword that to something like: > > Prevent tracing of preempt_disable() in get_cpu_var() in > kvm_clock_read(). When CONFIG_DEBUG_PREEMPT is enabled, > preempt_disable/enable() are traced and this causes the function_graph > tracer to go into an infinite recursion. By open coding the > preempt_disable() around the get_cpu_var(), we can use the notrace > version which prevents preempt_disable/enable() from being traced and > prevents the recursion. > > Something like the above. Thanks, I adopted your wording. > > > > Based on a similar patch for Xen from Jeremy Fitzhardinge. > > > > Signed-off-by: Avi Kivity <avi@xxxxxxxxxx> > > This was exactly my first thought, but I was thinking it may be better > to have a get_cpu_var_notrace() than to have to open code this stuff. > Maybe there's not that many users that open code is not an issue. I'll > still want to add that recursion protection with the warn on though. > What about function traces? Will any noninlined calls cause the same problem? -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
