Fix: don't access packet header for stream_id and stream_instance_id getters stable-2.10-backport
authorMathieu Desnoyers <mathieu.desnoyers@efficios.com>
Wed, 10 Apr 2019 14:48:57 +0000 (10:48 -0400)
committerJonathan Rajotte <jonathan.rajotte-julien@efficios.com>
Wed, 10 Apr 2019 15:06:31 +0000 (11:06 -0400)
commit509c3da905302a1ffb6ad0fa6e367a08b4d3fbaa
treeb98c35c938954e43f25a315bbe1413ca2cbadd78
parent43bd70bc9e00729ddf3825bba326b221b20a653f
Fix: don't access packet header for stream_id and stream_instance_id getters

The stream ID and stream instance ID are invariant for a stream, so
there is no point reading them from the packet header currently owned by
the consumer (between get/put subbuf).

Actually, the consumer try to access the stream_id from the live timer
when sending a live beacon without getting the reader subbuffer first,
which can trigger WARN_ON safety nets in libringbuffer. This safety
net triggers a kernel OOPS report and disables tracing for that channel.

In the case where a ring buffer does not have any data ready, it makes
no sense to try to get a subbuffer for reading anyway, so the approach
was broken.

So return the stream id and stream instance id from the internal
data structures rather than reading it from the ring buffer.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
lttng-ring-buffer-client.h
This page took 0.025544 seconds and 5 git commands to generate.