• Steven Rostedt's avatar
    ring-buffer: Fix typo of time extends per page · d0134324
    Steven Rostedt authored
    Time stamps for the ring buffer are created by the difference between
    two events. Each page of the ring buffer holds a full 64 bit timestamp.
    Each event has a 27 bit delta stamp from the last event. The unit of time
    is nanoseconds, so 27 bits can hold ~134 milliseconds. If two events
    happen more than 134 milliseconds apart, a time extend is inserted
    to add more bits for the delta. The time extend has 59 bits, which
    is good for ~18 years.
    
    Currently the time extend is committed separately from the event.
    If an event is discarded before it is committed, due to filtering,
    the time extend still exists. If all events are being filtered, then
    after ~134 milliseconds a new time extend will be added to the buffer.
    
    This can only happen till the end of the page. Since each page holds
    a full timestamp, there is no reason to add a time extend to the
    beginning of a page. Time extends can only fill a page that has actual
    data at the beginning, so there is no fear that time extends will fill
    more than a page without any data.
    
    When reading an event, a loop is made to skip over time extends
    since they are only used to maintain the time stamp and are never
    given to the caller. As a paranoid check to prevent the loop running
    forever, with the knowledge that time extends may only fill a page,
    a check is made that tests the iteration of the loop, and if the
    iteration is more than the number of time extends that can fit in a page
    a warning is printed and the ring buffer is disabled (all of ftrace
    is also disabled with it).
    
    There is another event type that is called a TIMESTAMP which can
    hold 64 bits of data in the theoretical case that two events happen
    18 years apart. This code has not been implemented, but the name
    of this event exists, as well as the structure for it. The
    size of a TIMESTAMP is 16 bytes, where as a time extend is only
    8 bytes. The macro used to calculate how many time extends can fit on
    a page used the TIMESTAMP size instead of the time extend size
    cutting the amount in half.
    
    The following test case can easily trigger the warning since we only
    need to have half the page filled with time extends to trigger the
    warning:
    
     # cd /sys/kernel/debug/tracing/
     # echo function > current_tracer
     # echo 'common_pid < 0' > events/ftrace/function/filter
     # echo > trace
     # echo 1 > trace_marker
     # sleep 120
     # cat trace
    
    Enabling the function tracer and then setting the filter to only trace
    functions where the process id is negative (no events), then clearing
    the trace buffer to ensure that we have nothing in the buffer,
    then write to trace_marker to add an event to the beginning of a page,
    sleep for 2 minutes (only 35 seconds is probably needed, but this
    guarantees the bug), and then finally reading the trace which will
    trigger the bug.
    
    This patch fixes the typo and prevents the false positive of that warning.
    Reported-by: default avatarHans J. Koch <hjk@linutronix.de>
    Tested-by: default avatarHans J. Koch <hjk@linutronix.de>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Stable Kernel <stable@kernel.org>
    Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
    d0134324
ring_buffer.c 101 KB