Jeff Dike wrote:
> jreiser@BitWagon.com said:
>
>>In order to prevent races between valgrind for UML and kernel
>>allocators which valgrind does not "know", then the VALGRIND_*
>>declarations being added to kernel allocators should allow for
>>expressing the concept "atomically change state in both allocator and
>>valgrind".
>
>
> What are you talking about?
>
> There are no atomicity problems between UML and valgrind.
If so, then you are fortunate. But in the abstract, and more importantly
in the mind of the maintainer of a lock-free SMP allocator who is trying
to allow simultaneous allocation and valgrind of the allocator, then such
atomicity problems are real. The VALGRIND_* statements should allow
the conscientious and meticulous maintainer to express the correct
semantics, even though the current implementation of valgrind for UML
might not [have to] take advantage of all of the properties of such a
precise description. If nothing else, then such a maintainer will invent
his own VALGRIND_* usage to express simultaneous {allocator, valgrind}
state transitions precisely.
-- John Reiser, jreiser@BitWagon.com- 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/
This archive was generated by hypermail 2b29 : Mon Dec 23 2002 - 22:00:29 EST