Data races in freeGroup
The block allocator's freeGroup
function commits a rather serious concurrency sin in its block coalescence
logic: When freeing a block it looks at bd->free
of the previous/next block
to see whether it is allocated. However, the free'ing thread likely does not
own the previous/next block, nor do we make any attempt to synchronize with
the thread that does own it; this makes this access a data race.
The original design argued that this was correct because bd->free
will
only take a value of -1 when the block is free and thereby owned by the
storage manager. However, this is nevertheless unsafe under the C11 data
model, which guarantees no particular semantics for data races.
We currently assume (and hope) we won't see torn values and consequently
we will never see bd->free == -1
for an allocated block which we do not
own. However, this is all extremely dodgy and really ought to be revisited.