Messages in this thread | | | Date | Sat, 21 Dec 2002 08:15:27 -0800 | From | John Reiser <> | Subject | Re: Valgrind meets UML |
| |
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/
| |