Messages in this thread | | | Date | Wed, 31 Mar 2010 10:27:36 -0400 | From | Mathieu Desnoyers <> | Subject | Re: [patch 1/5] Debugobjects transition check |
| |
* 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
| |