Re: Valgrind meets UML

[John Reiser <jreiser@BitWagon.com>]

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".  One example might be
	VALGRIND_STORE_AND_UPDATE(ptr, value, n, ranges)
with semantics
	struct vg_update {
		void const *addr;  /* valgrind itself never changes the contents */
		unsigned length;
		enum {vg_na, vg_w, vg_rw, vg_ro} new_state;
	} *ranges;

	valgrind_lock();
	*ptr = value;
	valgrind_update(n, ranges);  /* ranges should not overlap */
	valgrind_unlock();

In general there is a need for such a primitive for each kind of atomic
operation performed by an allocator: on x86, anything with an explicit or
implicit LOCK prefix (INC, DEC, ADD, SUB, AND, OR, XOR, BTR, BTS, BTC, XADD,
XCHG, CMPXCHG are the most likely).  Of course, most actual allocators
already use an explicit software lock which in some cases can subsume the
valgrind lock.  But there are lockless allocators; a circular buffer between
consumer and producer is the simplest.  Also, there are allocators which use
a hardware device as part of the lock: UART FIFO, circular buffer with
hardware on one side, SCSI command queue, etc.

-- 
John Reiser, jreiser@BitWagon.com