Re: [patch 1/5] Debugobjects transition check

[Mathieu Desnoyers <mathieu.desnoyers@efficios.com>]

* Thomas Gleixner (tglx@linutronix.de) wrote:
> On Wed, 31 Mar 2010, Mathieu Desnoyers wrote:
> 
> > * Thomas Gleixner (tglx@linutronix.de) wrote:
> > > On Mon, 29 Mar 2010, Mathieu Desnoyers wrote:
> > > 
> > > > Implement a basic state machine checker in the debugobjects.
> > > 
> > > Can you please add some real explanation how that checker works and
> > > why we want to have it ?
> > 
> > We can add this to the changelog. Is it worth it to create a Documentation file
> > for it ?
> 
> I meant the changelog. The "Implement ...." line was not really helpful :)
>  
> > 
> > This state machine checker detects races and inconsistencies within the "active"
> > life of a debugobject. The checker only keeps track of the current state; all
> > the state machine logic is kept at the object instance level.
> > 
> > The checker works by adding a supplementary "unsigned int astate" field to the
> > debug_obj structure. It keeps track of the current "active state" of the object.
> > 
> > The only constraints that are imposed on the states by the debugobjects system
> > is that:
> > 
> > - activation of an object sets the current active state to 0,
> > - deactivation of an object expects the current active state to be 0.
> > 
> > For the rest of the states, the state mapping is determined by the specific
> > object instance. Therefore, the logic keeping track of the state machine is
> > within the specialized instance, without any need to know about it at the
> > debugobject level.
> > 
> > The current object active state is changed by calling:
> > 
> > debug_object_active_state(addr, descr, expect, next)
> > 
> > where "expect" is the expected state and "next" is the next state to move to if
> > the expected state is found. A warning is generated if the expected is not
> > found.
> 
> Does it only warn or is there a callback to fixup things as well ?

For the moment, it only warns. I have not seen the need for a fixup callback
yet. It might become useful at some point, but I prefer to proceed
incrementally. This kind of callback could become quite big too, because it
would have to deal with transitions "from each to each" states of the system,
with, in the worse case scenario, different fixups for each situation.

Just for the specific case of "do RCU batch", when detecting that a non-queued
rcu head is there for execution, there are a few cases to consider:

- List corruption
  - Appears in two lists.
  - Appears in the same list twice.
- Race (two threads reading the list at the same time).
- ...

I am probably forgetting about others. So one way to fixup this would be not to
execute the callback, but even then, the lists might be corrupted. So it's not
at all clear to me if we can do much better than reporting the inconsistency
without increasing intrusiveness. But maybe I just need more imagination. ;)

Thanks,

Mathieu

> 
> Thanks,
> 
> 	tglx

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com