13 Oct, 2019

1 commit

  • Added various checks on open tracefs calls to see if tracefs is in lockdown
    mode, and if so, to return -EPERM.

    Note, the event format files (which are basically standard on all machines)
    as well as the enabled_functions file (which shows what is currently being
    traced) are not lockde down. Perhaps they should be, but it seems counter
    intuitive to lockdown information to help you know if the system has been
    modified.

    Link: http://lkml.kernel.org/r/CAHk-=wj7fGPKUspr579Cii-w_y60PtRaiDgKuxVtBAMK0VNNkA@mail.gmail.com

    Suggested-by: Linus Torvalds
    Signed-off-by: Steven Rostedt (VMware)

    Steven Rostedt (VMware)
     

26 Sep, 2018

1 commit


17 Aug, 2018

1 commit


26 Mar, 2018

1 commit

  • Some functions definitions have either the initial open brace and/or
    the closing brace outside of column 1.

    Move those braces to column 1.

    This allows various function analyzers like gnu complexity to work
    properly for these modified functions.

    Signed-off-by: Joe Perches
    Acked-by: Andy Shevchenko
    Acked-by: Paul Moore
    Acked-by: Alex Deucher
    Acked-by: Dave Chinner
    Reviewed-by: Darrick J. Wong
    Acked-by: Alexandre Belloni
    Acked-by: Martin K. Petersen
    Acked-by: Takashi Iwai
    Acked-by: Mauro Carvalho Chehab
    Acked-by: Rafael J. Wysocki
    Acked-by: Nicolin Chen
    Acked-by: Martin K. Petersen
    Acked-by: Steven Rostedt (VMware)
    Signed-off-by: Jiri Kosina

    Joe Perches
     

20 Jun, 2016

1 commit

  • If a task uses a non constant string for the format parameter in
    trace_printk(), then the trace_printk_fmt variable is set to NULL. This
    variable is then saved in the __trace_printk_fmt section.

    The function hold_module_trace_bprintk_format() checks to see if duplicate
    formats are used by modules, and reuses them if so (saves them to the list
    if it is new). But this function calls lookup_format() that does a strcmp()
    to the value (which is now NULL) and can cause a kernel oops.

    This wasn't an issue till 3debb0a9ddb ("tracing: Fix trace_printk() to print
    when not using bprintk()") which added "__used" to the trace_printk_fmt
    variable, and before that, the kernel simply optimized it out (no NULL value
    was saved).

    The fix is simply to handle the NULL pointer in lookup_format() and have the
    caller ignore the value if it was NULL.

    Link: http://lkml.kernel.org/r/1464769870-18344-1-git-send-email-zhengjun.xing@intel.com

    Reported-by: xingzhen
    Acked-by: Namhyung Kim
    Fixes: 3debb0a9ddb ("tracing: Fix trace_printk() to print when not using bprintk()")
    Cc: stable@vger.kernel.org # v3.5+
    Signed-off-by: Steven Rostedt

    Steven Rostedt (Red Hat)
     

23 Mar, 2016

1 commit

  • The trace_printk() code will allocate extra buffers if the compile detects
    that a trace_printk() is used. To do this, the format of the trace_printk()
    is saved to the __trace_printk_fmt section, and if that section is bigger
    than zero, the buffers are allocated (along with a message that this has
    happened).

    If trace_printk() uses a format that is not a constant, and thus something
    not guaranteed to be around when the print happens, the compiler optimizes
    the fmt out, as it is not used, and the __trace_printk_fmt section is not
    filled. This means the kernel will not allocate the special buffers needed
    for the trace_printk() and the trace_printk() will not write anything to the
    tracing buffer.

    Adding a "__used" to the variable in the __trace_printk_fmt section will
    keep it around, even though it is set to NULL. This will keep the string
    from being printed in the debugfs/tracing/printk_formats section as it is
    not needed.

    Reported-by: Vlastimil Babka
    Fixes: 07d777fe8c398 "tracing: Add percpu buffers for trace_printk()"
    Cc: stable@vger.kernel.org # v3.5+
    Signed-off-by: Steven Rostedt

    Steven Rostedt (Red Hat)
     

05 Jan, 2016

1 commit

  • When we do cat /sys/kernel/debug/tracing/printk_formats, we hit kernel
    panic at t_show.

    general protection fault: 0000 [#1] PREEMPT SMP
    CPU: 0 PID: 2957 Comm: sh Tainted: G W O 3.14.55-x86_64-01062-gd4acdc7 #2
    RIP: 0010:[]
    [] t_show+0x22/0xe0
    RSP: 0000:ffff88002b4ebe80 EFLAGS: 00010246
    RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000004
    RDX: 0000000000000004 RSI: ffffffff81fd26a6 RDI: ffff880032f9f7b1
    RBP: ffff88002b4ebe98 R08: 0000000000001000 R09: 000000000000ffec
    R10: 0000000000000000 R11: 000000000000000f R12: ffff880004d9b6c0
    R13: 7365725f6d706400 R14: ffff880004d9b6c0 R15: ffffffff82020570
    FS: 0000000000000000(0000) GS:ffff88003aa00000(0063) knlGS:00000000f776bc40
    CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033
    CR2: 00000000f6c02ff0 CR3: 000000002c2b3000 CR4: 00000000001007f0
    Call Trace:
    [] seq_read+0x2f6/0x3e0
    [] vfs_read+0x9b/0x160
    [] SyS_read+0x49/0xb0
    [] ia32_do_call+0x13/0x13
    ---[ end trace 5bd9eb630614861e ]---
    Kernel panic - not syncing: Fatal exception

    When the first time find_next calls find_next_mod_format, it should
    iterate the trace_bprintk_fmt_list to find the first print format of
    the module. However in current code, start_index is smaller than *pos
    at first, and code will not iterate the list. Latter container_of will
    get the wrong address with former v, which will cause mod_fmt be a
    meaningless object and so is the returned mod_fmt->fmt.

    This patch will fix it by correcting the start_index. After fixed,
    when the first time calls find_next_mod_format, start_index will be
    equal to *pos, and code will iterate the trace_bprintk_fmt_list to
    get the right module printk format, so is the returned mod_fmt->fmt.

    Link: http://lkml.kernel.org/r/5684B900.9000309@intel.com

    Cc: stable@vger.kernel.org # 3.12+
    Fixes: 102c9323c35a8 "tracing: Add __tracepoint_string() to export string pointers"
    Signed-off-by: Qiu Peiyang
    Signed-off-by: Steven Rostedt

    Qiu Peiyang
     

30 Sep, 2015

1 commit


23 Jan, 2015

2 commits


14 Nov, 2014

1 commit

  • Printing a single character to a seqfile might as well be done with
    seq_putc instead of seq_puts; this avoids a strlen() call and a memory
    access. It also shaves another few bytes off the generated code.

    Link: http://lkml.kernel.org/r/1415479332-25944-4-git-send-email-linux@rasmusvillemoes.dk

    Signed-off-by: Rasmus Villemoes
    Signed-off-by: Steven Rostedt

    Rasmus Villemoes
     

27 Jul, 2013

1 commit

  • There are several tracepoints (mostly in RCU), that reference a string
    pointer and uses the print format of "%s" to display the string that
    exists in the kernel, instead of copying the actual string to the
    ring buffer (saves time and ring buffer space).

    But this has an issue with userspace tools that read the binary buffers
    that has the address of the string but has no access to what the string
    itself is. The end result is just output that looks like:

    rcu_dyntick: ffffffff818adeaa 1 0
    rcu_dyntick: ffffffff818adeb5 0 140000000000000
    rcu_dyntick: ffffffff818adeb5 0 140000000000000
    rcu_utilization: ffffffff8184333b
    rcu_utilization: ffffffff8184333b

    The above is pretty useless when read by the userspace tools. Ideally
    we would want something that looks like this:

    rcu_dyntick: Start 1 0
    rcu_dyntick: End 0 140000000000000
    rcu_dyntick: Start 140000000000000 0
    rcu_callback: rcu_preempt rhp=0xffff880037aff710 func=put_cred_rcu 0/4
    rcu_callback: rcu_preempt rhp=0xffff880078961980 func=file_free_rcu 0/5
    rcu_dyntick: End 0 1

    The trace_printk() which also only stores the address of the string
    format instead of recording the string into the buffer itself, exports
    the mapping of kernel addresses to format strings via the printk_format
    file in the debugfs tracing directory.

    The tracepoint strings can use this same method and output the format
    to the same file and the userspace tools will be able to decipher
    the address without any modification.

    The tracepoint strings need its own section to save the strings because
    the trace_printk section will cause the trace_printk() buffers to be
    allocated if anything exists within the section. trace_printk() is only
    used for debugging and should never exist in the kernel, we can not use
    the trace_printk sections.

    Add a new tracepoint_str section that will also be examined by the output
    of the printk_format file.

    Cc: Paul E. McKenney
    Signed-off-by: Steven Rostedt

    Steven Rostedt (Red Hat)
     

24 Apr, 2012

1 commit

  • Currently, trace_printk() uses a single buffer to write into
    to calculate the size and format needed to save the trace. To
    do this safely in an SMP environment, a spin_lock() is taken
    to only allow one writer at a time to the buffer. But this could
    also affect what is being traced, and add synchronization that
    would not be there otherwise.

    Ideally, using percpu buffers would be useful, but since trace_printk()
    is only used in development, having per cpu buffers for something
    never used is a waste of space. Thus, the use of the trace_bprintk()
    format section is changed to be used for static fmts as well as dynamic ones.
    Then at boot up, we can check if the section that holds the trace_printk
    formats is non-empty, and if it does contain something, then we
    know a trace_printk() has been added to the kernel. At this time
    the trace_printk per cpu buffers are allocated. A check is also
    done at module load time in case a module is added that contains a
    trace_printk().

    Once the buffers are allocated, they are never freed. If you use
    a trace_printk() then you should know what you are doing.

    A buffer is made for each type of context:

    normal
    softirq
    irq
    nmi

    The context is checked and the appropriate buffer is used.
    This allows for totally lockless usage of trace_printk(),
    and they no longer even disable interrupts.

    Requested-by: Peter Zijlstra
    Signed-off-by: Steven Rostedt

    Steven Rostedt
     

11 Aug, 2011

1 commit


09 Jun, 2011

1 commit

  • The fix to fix the printk_formats of modules broke the
    printk_formats of trace_printks in the kernel.

    The update of what to show via the seq_file was only updated
    if the passed in fmt was NULL, which happens only on the first
    iteration. The result was showing the first format every time
    instead of iterating through the available formats.

    Signed-off-by: Steven Rostedt

    Steven Rostedt
     

05 Apr, 2011

2 commits

  • The file debugfs/tracing/printk_formats maps the addresses
    to the formats that are used by trace_bprintk() so that userspace
    tools can read the buffer and be able to decode trace_bprintk events
    to get the format saved when reading the ring buffer directly.

    This is because trace_bprintk() does not store the format into the
    buffer, but just the address of the format, which is hidden in
    the kernel memory.

    But currently it only exports trace_bprintk()s from the kernel core
    and not for modules. The modules need their formats exported
    as well.

    Signed-off-by: Steven Rostedt

    Steven Rostedt
     
  • The trace_printk() formats for modules do not show up in the
    debugfs/tracing/printk_formats file. Only the formats that are
    for trace_printk()s that are in the kernel core.

    To facilitate the change to add trace_printk() formats from modules
    into that file as well, we need to convert the structure that
    holds the formats from char fmt[], into const char *fmt,
    and allocate them separately.

    Signed-off-by: Steven Rostedt

    Steven Rostedt
     

19 Sep, 2009

1 commit

  • Now that the last users of markers have migrated to the event
    tracer we can kill off the (now orphan) support code.

    Signed-off-by: Christoph Hellwig
    Acked-by: Mathieu Desnoyers
    Cc: Steven Rostedt
    Cc: Frederic Weisbecker
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Christoph Hellwig
     

23 Jul, 2009

1 commit

  • Since the trace_printk may use pointers to the format fields
    in the buffer, they are exported via debugfs/tracing/printk_formats.
    This is used by utilities that read the ring buffer in binary format.
    It helps the utilities map the address of the format in the binary
    buffer to what the printf format looks like.

    Unfortunately, the way the output code works, it exports the address
    of the pointer to the format address, and not the format address
    itself. This makes the file totally useless in trying to figure
    out what format string a binary address belongs to.

    Signed-off-by: Steven Rostedt

    Steven Rostedt
     

24 Jun, 2009

1 commit

  • It's wrong to increment @pos in t_start(), otherwise we'll lose
    some entries when reading printk_formats, if the output is larger
    than PAGE_SIZE.

    Reported-by: Lai Jiangshan
    Reviewed-by: Liming Wang
    Signed-off-by: Li Zefan
    Cc: Steven Rostedt
    Cc: Frederic Weisbecker
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Li Zefan
     

07 Apr, 2009

1 commit


20 Mar, 2009

1 commit


13 Mar, 2009

2 commits

  • The binary printk saves a pointer to the format string in the ring buffer.
    On output, the format is processed. But if the user is reading the
    ring buffer through a binary interface, the pointer is meaningless.

    This patch creates a file called printk_formats that maps the pointers
    to the formats.

    # cat /debug/tracing/printk_formats
    0xffffffff80713d40 : "irq_handler_entry: irq=%d handler=%s\n"
    0xffffffff80713d48 : "lock_acquire: %s%s%s\n"
    0xffffffff80713d50 : "lock_release: %s\n"

    Signed-off-by: Steven Rostedt

    Steven Rostedt
     
  • Impact: fix callsites with dynamic format strings

    Since its new binary implementation, trace_printk() internally uses static
    containers for the format strings on each callsites. But the value is
    assigned once at build time, which means that it can't take dynamic
    formats.

    So this patch unearthes the raw trace_printk implementation for the callers
    that will need trace_printk to be able to carry these dynamic format
    strings. The trace_printk() macro will use the appropriate implementation
    for each callsite. Most of the time however, the binary implementation will
    still be used.

    The other impact of this patch is that mmiotrace_printk() will use the old
    implementation because it calls the low level trace_vprintk and we can't
    guess here whether the format passed in it is dynamic or not.

    Some parts of this patch have been written by Steven Rostedt (most notably
    the part that chooses the appropriate implementation for each callsites).

    Signed-off-by: Frederic Weisbecker
    Signed-off-by: Steven Rostedt

    Frederic Weisbecker
     

07 Mar, 2009

1 commit

  • Impact: faster and lighter tracing

    Now that we have trace_bprintk() which is faster and consume lesser
    memory than trace_printk() and has the same purpose, we can now drop
    the old implementation in favour of the binary one from trace_bprintk(),
    which means we move all the implementation of trace_bprintk() to
    trace_printk(), so the Api doesn't change except that we must now use
    trace_seq_bprintk() to print the TRACE_PRINT entries.

    Some changes result of this:

    - Previously, trace_bprintk depended of a single tracer and couldn't
    work without. This tracer has been dropped and the whole implementation
    of trace_printk() (like the module formats management) is now integrated
    in the tracing core (comes with CONFIG_TRACING), though we keep the file
    trace_printk (previously trace_bprintk.c) where we can find the module
    management. Thus we don't overflow trace.c

    - changes some parts to use trace_seq_bprintk() to print TRACE_PRINT entries.

    - change a bit trace_printk/trace_vprintk macros to support non-builtin formats
    constants, and fix 'const' qualifiers warnings. But this is all transparent for
    developers.

    - etc...

    V2:

    - Rebase against last changes
    - Fix mispell on the changelog

    V3:

    - Rebase against last changes (moving trace_printk() to kernel.h)

    Signed-off-by: Frederic Weisbecker
    Acked-by: Steven Rostedt
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Frederic Weisbecker