Re: Valgrind meets UML

[John Reiser <jreiser@BitWagon.com>]

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