Hi Vegard,

On Wed, Apr 2, 2008 at 6:08 PM, Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote:
quoted text
> > Would the following be an appropriate fix?  It seems to me to be in
> > the same spirit as the existing check for s->ctor.
 
On Wed, 2 Apr 2008, Vegard Nossum wrote:
quoted text
> In my opinion, no.
> 
> It would fix the false positives, but would in fact also hide cases
> such as this one with cfq, e.g. the real cases of mis-use.

Yes, but we might as well put Paul's patch in now and remove that later 
when we have a proper fix, no?

On Wed, 2 Apr 2008, Vegard Nossum wrote:
quoted text
> Peter Zijlstra suggested this:
> > It would have to register an call_rcu callback itself in order to mark
> > it freed - and handle the race with the object being handed out again.
> 
> I will try to look into this -- for now, I need to understand RCU
> first (I've seen your LWN articles -- great work! :-))

Well, maybe we can add two new states: RCU_FREED and RCU_VALIDATED? The 
object is flagged with the first one as soon as an object is handed over 
to kmem_cache_free() and the latter needs to hook to the validation phase 
of RCU (how is that done btw?). Then kmemcheck could even give a better 
error message: "RCU-freed object used without validation."

And with delayed free for kmemcheck we discussed before, we'd hold on to 
the objects long enough to actually see these error conditions.

			Pekka
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/