Fix: handle concurrent flush vs get_next_subbuf on metadata cache
authorMathieu Desnoyers <mathieu.desnoyers@efficios.com>
Fri, 26 Sep 2014 00:33:21 +0000 (20:33 -0400)
committerMathieu Desnoyers <mathieu.desnoyers@efficios.com>
Fri, 26 Sep 2014 00:44:48 +0000 (20:44 -0400)
The "flush" operation can be performed on the metadata file descriptor
concurrently with get_next_subbuffer operations by different processes
(e.g. lttng session daemon issuing flush at "stop" concurrently with
consumer daemon issuing get_next_subbuf for metadata I/O). We need
to protect the metadata cache from those concurrent use by introducing a
mutex.

This fixes a race where metadata from a kernel trace is corrupted due to
this scenario. The corruption shows up like the same metadata content (a
metadata packet) being written twice consecutively in the metadata
stream, thus triggering a babeltrace "parse error" when trying to read
the trace.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

No differences found
This page took 0.025428 seconds and 4 git commands to generate.