Re: [RFC PATCH 03/11] Annotate core code that should not be traced

[Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>]

* Steven Rostedt (rostedt@goodmis.org) wrote:
> 
> 
 ....
> >
> > >  {
> > >  	struct irq_desc *desc = irq_desc + irq;
> > >  	struct irqaction *action;
> > > Index: linux-compile.git/kernel/lockdep.c
> > > ===================================================================
> > > --- linux-compile.git.orig/kernel/lockdep.c	2007-12-20 01:00:29.000000000 -0500
> > > +++ linux-compile.git/kernel/lockdep.c	2007-12-20 01:00:48.000000000 -0500
> > > @@ -270,14 +270,14 @@ static struct list_head chainhash_table[
> > >  	((key1) >> (64-MAX_LOCKDEP_KEYS_BITS)) ^ \
> > >  	(key2))
> > >
> > > -void lockdep_off(void)
> > > +notrace void lockdep_off(void)
> > >  {
> > >  	current->lockdep_recursion++;
> > >  }
> > >
> >
> > Due to interrupt disabling in your tracing code I suppose.
> 
> probably. Again, this came from the RT patch. And this stuff has been in
> the patch for ages. So some of it was just plain paranoia. Others were
> needed for some kind of tracing.
> 
> BTW, I'm curious? How do you handle NMIs and tracing. Do you use a
> separate buffer for storing your data on NMIs or do you have some kind of
> cmpxchg that can atomically reserve parts of the trace buffer?
> 

Because I want to deal with weird cases like :

kernel calling tracing code, causing a user-space page fault, which
calls the tracer, which could be interrupted by an NMI, it would become
tricky to find out how many contexts could be stacked in the worse case
for each architecture. Therefore, using a cmpxchg-based algorithm is the
solution I used. However, in order to make this fast, I extented the
"local atomic operations" to offer a local_cmpxchg.

Mathieu


-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68