LTTng-UST and modules ring buffers timestamp_end value may not include last events in the packet (LTTng 2.2+)
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 <email@example.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 <firstname.lastname@example.org>