This issue affects only architectures without efficient unaligned
accesses, only when a context field with larger alignment follows a
context field with smaller alignment. It generates unreadable traces
when such context fields are enabled in this configuration.
Accessing the lttng channel and lttng session from the metadata ring
buffer client is a bad idea, because we don't have any reference
ensuring those are valid for the lifetime of the metadata cache.
Therefore, rather than keeping a lttng channel as private data pointer
for the metadata ring buffer channel, keep a pointer to the metadata
cache instead: this will ensure we don't shoot ourself in the foot and
access data we for which coherency is not guaranteed (we don't hold any
reference to it).
Anyway, the only reason why we needed to access the lttng session from
the metadata client in the first place was the UUID of the session. Copy
it into the metadata cache instead.
Fix: handle concurrent flush vs get_next_subbuf on metadata cache
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.
