LTTng

In the following scenario, lttng-ust and lttng-modules ring buffer code may not strictly respect the guarantee about packet header [timestamp_begin, timestamp_end] range including timestamps of all events contained in the packet.

Indeed, if we have the prior-to-last event (with timestamp T) written in the packet interrupted or preempted before it increments the commit counter, and then the last event for the packet with timestamp (T+1) written and committed, it will be up to the commit counter increment of event with timestamp T to perform the packet delivery, and therefore set the value for the timestamp_end.

However, that timestamp is taken from the event reservation, and will not cover T+1.

This issue was introduced in LTTng 2.2:

commit 969771a1536069d8f3f05e4836f5ef746d9b9a11
Author: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Date:   Sun Nov 24 04:11:16 2013 -0500

    Fix: eliminate timestamp overlap between packets

    By using the timestamp sampled at space reservation when the packet is
    being filled as "end timestamp" for a packet, we can ensure there is no
    overlap between packet timestamp ranges, so that packet timestamp end <=
    following packets timestamp begin.

    Overlap between consecutive packets becomes an issue when the end
    timestamp of a packet is greater than the end timestamp of a following
    packet, IOW a packet completely contains the timestamp range of a
    following packet.  This kind of situation does not allow trace viewers
    to do binary search within the packet timestamps. This kind of situation
    will typically never occur if packets are significantly larger than
    event size, but this fix ensures it can never even theoretically happen.

    The only case where packets can still theoretically overlap is if they
    have equal begin and end timestamps, which is valid.

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