lkml.org 
[lkml]   [2002]   [Dec]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Valgrind meets UML
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

-
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/

\
 
 \ /
  Last update: 2005-03-22 13:31    [W:0.078 / U:1.764 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site