24 Dec, 2015

1 commit

  • commit 5ac48378414d ("tracing: Use trace_seq_used() and seq_buf_used()
    instead of len") changed the tracing code to use trace_seq_used() and
    seq_buf_used() instead of using the seq_buf len directly to avoid
    overflow issues, but missed a spot in seq_buf_to_user() that makes use
    of s->len.

    Cleaned up the code a bit as well per suggestion of Steve Rostedt.

    Link: http://lkml.kernel.org/r/1447703848-2951-1-git-send-email-jsnitsel@redhat.com

    Signed-off-by: Jerry Snitselaar
    Signed-off-by: Steven Rostedt

    Jerry Snitselaar
     

05 Mar, 2015

1 commit

  • In seq_buf_bprintf(), bstr_printf() is used to copy the format into the
    buffer remaining in the seq_buf structure. The return of bstr_printf()
    is the amount of characters written to the buffer excluding the '\0',
    unless the line was truncated!

    If the line copied does not fit, it is truncated, and a '\0' is added
    to the end of the buffer. But in this case, '\0' is included in the length
    of the line written. To know if the buffer had overflowed, the return
    length will be the same or greater than the length of the buffer passed in.

    The check in seq_buf_bprintf() only checked if the length returned from
    bstr_printf() would fit in the buffer, as the seq_buf_bprintf() is only
    to be an all or nothing command. It either writes all the string into
    the seq_buf, or none of it. If the string is truncated, the pointers
    inside the seq_buf must be reset to what they were when the function was
    called. This is not the case. On overflow, it copies only part of the string.

    The fix is to change the overflow check to see if the length returned from
    bstr_printf() is less than the length remaining in the seq_buf buffer, and not
    if it is less than or equal to as it currently does. Then seq_buf_bprintf()
    will know if the write from bstr_printf() was truncated or not.

    Link: http://lkml.kernel.org/r/1425500481.2712.27.camel@perches.com

    Cc: stable@vger.kernel.org
    Reported-by: Joe Perches
    Signed-off-by: Steven Rostedt

    Steven Rostedt (Red Hat)
     

04 Mar, 2015

1 commit

  • In seq_buf_vprintf(), vsnprintf() is used to copy the format into the
    buffer remaining in the seq_buf structure. The return of vsnprintf()
    is the amount of characters written to the buffer excluding the '\0',
    unless the line was truncated!

    If the line copied does not fit, it is truncated, and a '\0' is added
    to the end of the buffer. But in this case, '\0' is included in the length
    of the line written. To know if the buffer had overflowed, the return
    length will be the same as the length of the buffer passed in.

    The check in seq_buf_vprintf() only checked if the length returned from
    vsnprintf() would fit in the buffer, as the seq_buf_vprintf() is only
    to be an all or nothing command. It either writes all the string into
    the seq_buf, or none of it. If the string is truncated, the pointers
    inside the seq_buf must be reset to what they were when the function was
    called. This is not the case. On overflow, it copies only part of the string.

    The fix is to change the overflow check to see if the length returned from
    vsnprintf() is less than the length remaining in the seq_buf buffer, and not
    if it is less than or equal to as it currently does. Then seq_buf_vprintf()
    will know if the write from vsnpritnf() was truncated or not.

    Cc: stable@vger.kernel.org
    Signed-off-by: Steven Rostedt

    Steven Rostedt (Red Hat)
     

14 Feb, 2015

1 commit

  • Now that all bitmap formatting usages have been converted to
    '%*pb[l]', the separate formatting functions are unnecessary. The
    following functions are removed.

    * bitmap_scn[list]printf()
    * cpumask_scnprintf(), cpulist_scnprintf()
    * [__]nodemask_scnprintf(), [__]nodelist_scnprintf()
    * seq_bitmap[_list](), seq_cpumask[_list](), seq_nodemask[_list]()
    * seq_buf_bitmask()

    Signed-off-by: Tejun Heo
    Cc: Rusty Russell
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Tejun Heo
     

20 Nov, 2014

1 commit

  • The seq_buf functions are rather useful outside of tracing. Instead
    of having it be dependent on CONFIG_TRACING, move the code into lib/
    and allow other users to have access to it even when tracing is not
    configured.

    The seq_buf utility is similar to the seq_file utility, but instead of
    writing sending data back up to userland, it writes it into a buffer
    defined at seq_buf_init(). This allows us to send a descriptor around
    that writes printf() formatted strings into it that can be retrieved
    later.

    It is currently used by the tracing facility for such things like trace
    events to convert its binary saved data in the ring buffer into an
    ASCII human readable context to be displayed in /sys/kernel/debug/trace.

    It can also be used for doing NMI prints safely from NMI context into
    the seq_buf and retrieved later and dumped to printk() safely. Doing
    printk() from an NMI context is dangerous because an NMI can preempt
    a current printk() and deadlock on it.

    Link: http://lkml.kernel.org/p/20140619213952.058255809@goodmis.org

    Tested-by: Jiri Kosina
    Acked-by: Jiri Kosina
    Reviewed-by: Petr Mladek
    Signed-off-by: Steven Rostedt

    Steven Rostedt (Red Hat)