26 Oct, 2020

1 commit

  • Use a more generic form for __section that requires quotes to avoid
    complications with clang and gcc differences.

    Remove the quote operator # from compiler_attributes.h __section macro.

    Convert all unquoted __section(foo) uses to quoted __section("foo").
    Also convert __attribute__((section("foo"))) uses to __section("foo")
    even if the __attribute__ has multiple list entry forms.

    Conversion done using the script at:

    https://lore.kernel.org/lkml/75393e5ddc272dc7403de74d645e6c6e0f4e70eb.camel@perches.com/2-convert_section.pl

    Signed-off-by: Joe Perches
    Reviewed-by: Nick Desaulniers
    Reviewed-by: Miguel Ojeda
    Signed-off-by: Linus Torvalds

    Joe Perches
     

08 Sep, 2020

1 commit

  • Stephen Rothwell reported:

    > Exported symbols need to be presumably 56 on 64 bit arches and the above symbol (including the '.')
    > is 56 characters long.

    Shorten the tracepoint symbol name.

    Fixes: d25e37d89dd2 ("tracepoint: Optimize using static_call()")
    Reported-by: Stephen Rothwell
    Signed-off-by: Peter Zijlstra
    Signed-off-by: Ingo Molnar
    Link: https://lore.kernel.org/r/20200908105743.GW2674@hirez.programming.kicks-ass.net

    peterz@infradead.org
     

01 Sep, 2020

1 commit

  • Currently the tracepoint site will iterate a vector and issue indirect
    calls to however many handlers are registered (ie. the vector is
    long).

    Using static_call() it is possible to optimize this for the common
    case of only having a single handler registered. In this case the
    static_call() can directly call this handler. Otherwise, if the vector
    is longer than 1, call a function that iterates the whole vector like
    the current code.

    [peterz: updated to new interface]

    Signed-off-by: Steven Rostedt (VMware)
    Signed-off-by: Peter Zijlstra (Intel)
    Signed-off-by: Ingo Molnar
    Cc: Linus Torvalds
    Link: https://lore.kernel.org/r/20200818135805.279421092@infradead.org

    Steven Rostedt (VMware)
     

04 Aug, 2020

2 commits

  • Just a small cleanup while I was touching this header.
    compiler_attributes.h does feature detection of these __attributes__(())
    and provides more concise ways to invoke them.

    Link: https://lkml.kernel.org/r/20200730224555.2142154-3-ndesaulniers@google.com

    Acked-by: Miguel Ojeda
    Signed-off-by: Nick Desaulniers
    Signed-off-by: Steven Rostedt (VMware)

    Nick Desaulniers
     
  • __tracepoint_string's have their string data stored in .rodata, and an
    address to that data stored in the "__tracepoint_str" section. Functions
    that refer to those strings refer to the symbol of the address. Compiler
    optimization can replace those address references with references
    directly to the string data. If the address doesn't appear to have other
    uses, then it appears dead to the compiler and is removed. This can
    break the /tracing/printk_formats sysfs node which iterates the
    addresses stored in the "__tracepoint_str" section.

    Like other strings stored in custom sections in this header, mark these
    __used to inform the compiler that there are other non-obvious users of
    the address, so they should still be emitted.

    Link: https://lkml.kernel.org/r/20200730224555.2142154-2-ndesaulniers@google.com

    Cc: Ingo Molnar
    Cc: Miguel Ojeda
    Cc: stable@vger.kernel.org
    Fixes: 102c9323c35a8 ("tracing: Add __tracepoint_string() to export string pointers")
    Reported-by: Tim Murray
    Reported-by: Simon MacMullen
    Suggested-by: Greg Hackmann
    Signed-off-by: Nick Desaulniers
    Signed-off-by: Steven Rostedt (VMware)

    Nick Desaulniers
     

23 Apr, 2020

1 commit

  • This macro was intentionally broken so that the kernel code is not
    poluted with such noargs macro used simply as markers. This use case
    can be satisfied by using dummy no inline functions. Just remove it.

    Link: http://lkml.kernel.org/r/20200413153246.8511-1-nborisov@suse.com

    Signed-off-by: Nikolay Borisov
    Signed-off-by: Steven Rostedt (VMware)

    Nikolay Borisov
     

05 Jun, 2019

1 commit

  • Based on 1 normalized pattern(s):

    this file is released under the gplv2 see the file copying for more
    details

    extracted by the scancode license scanner the SPDX license identifier

    GPL-2.0-only

    has been chosen to replace the boilerplate/reference in 3 file(s).

    Signed-off-by: Thomas Gleixner
    Reviewed-by: Armijn Hemel
    Reviewed-by: Allison Randal
    Cc: linux-spdx@vger.kernel.org
    Link: https://lkml.kernel.org/r/20190531081035.872590698@linutronix.de
    Signed-off-by: Greg Kroah-Hartman

    Thomas Gleixner
     

08 Apr, 2019

1 commit

  • Sometimes we want to define a tracepoint as a do-nothing function.
    So I introduce TRACE_EVENT_NOP, DECLARE_EVENT_CLASS_NOP and
    DEFINE_EVENT_NOP for this kind of usage.

    Link: http://lkml.kernel.org/r/1553602391-11926-2-git-send-email-laoar.shao@gmail.com

    Signed-off-by: Yafang Shao
    Signed-off-by: Steven Rostedt (VMware)

    Yafang Shao
     

04 Dec, 2018

1 commit

  • …k/linux-rcu into core/rcu

    Pull RCU changes from Paul E. McKenney:

    - Convert RCU's BUG_ON() and similar calls to WARN_ON() and similar.

    - Replace calls of RCU-bh and RCU-sched update-side functions
    to their vanilla RCU counterparts. This series is a step
    towards complete removal of the RCU-bh and RCU-sched update-side
    functions.

    ( Note that some of these conversions are going upstream via their
    respective maintainers. )

    - Documentation updates, including a number of flavor-consolidation
    updates from Joel Fernandes.

    - Miscellaneous fixes.

    - Automate generation of the initrd filesystem used for
    rcutorture testing.

    - Convert spin_is_locked() assertions to instead use lockdep.

    ( Note that some of these conversions are going upstream via their
    respective maintainers. )

    - SRCU updates, especially including a fix from Dennis Krein
    for a bag-on-head-class bug.

    - RCU torture-test updates.

    Signed-off-by: Ingo Molnar <mingo@kernel.org>

    Ingo Molnar
     

30 Nov, 2018

1 commit

  • After enabling KVM event tracing, almost all of trace_kvm_exit()'s
    printk shows

    "kvm_exit: IRQ: ..."

    even if the actual exception_type is NOT IRQ. More specifically,
    trace_kvm_exit() is defined in virt/kvm/arm/trace.h by TRACE_EVENT.

    This slight problem may have existed after commit e6753f23d961
    ("tracepoint: Make rcuidle tracepoint callers use SRCU"). There are
    two variables in trace_kvm_exit() and __DO_TRACE() which have the
    same name, *idx*. Thus the actual value of *idx* will be overwritten
    when tracing. Fix it by adding a simple prefix.

    Cc: Joel Fernandes
    Cc: Wang Haibin
    Cc: linux-trace-devel@vger.kernel.org
    Cc: stable@vger.kernel.org
    Fixes: e6753f23d961 ("tracepoint: Make rcuidle tracepoint callers use SRCU")
    Reviewed-by: Joel Fernandes (Google)
    Signed-off-by: Zenghui Yu
    Signed-off-by: Steven Rostedt (VMware)

    Zenghui Yu
     

28 Nov, 2018

1 commit

  • Now that synchronize_rcu() waits for preempt-disable regions of code
    as well as RCU read-side critical sections, synchronize_sched() can
    be replaced by synchronize_rcu(). Similarly, call_rcu_sched() can be
    replaced by call_rcu(). This commit therefore makes these changes.

    Signed-off-by: Paul E. McKenney
    Cc: Ingo Molnar
    Cc:
    Acked-by: Steven Rostedt (VMware)

    Paul E. McKenney
     

18 Oct, 2018

1 commit

  • commit 46e0c9be206f ("kernel: tracepoints: add support for relative
    references") changes the layout of the __tracepoint_ptrs section on
    architectures supporting relative references. However, it does so
    without turning struct tracepoint * const into const int elsewhere in
    the tracepoint code, which has the following side-effect:

    Setting mod->num_tracepoints is done in by module.c:

    mod->tracepoints_ptrs = section_objs(info, "__tracepoints_ptrs",
    sizeof(*mod->tracepoints_ptrs),
    &mod->num_tracepoints);

    Basically, since sizeof(*mod->tracepoints_ptrs) is a pointer size
    (rather than sizeof(int)), num_tracepoints is erroneously set to half the
    size it should be on 64-bit arch. So a module with an odd number of
    tracepoints misses the last tracepoint due to effect of integer
    division.

    So in the module going notifier:

    for_each_tracepoint_range(mod->tracepoints_ptrs,
    mod->tracepoints_ptrs + mod->num_tracepoints,
    tp_module_going_check_quiescent, NULL);

    the expression (mod->tracepoints_ptrs + mod->num_tracepoints) actually
    evaluates to something within the bounds of the array, but miss the
    last tracepoint if the number of tracepoints is odd on 64-bit arch.

    Fix this by introducing a new typedef: tracepoint_ptr_t, which
    is either "const int" on architectures that have PREL32 relocations,
    or "struct tracepoint * const" on architectures that does not have
    this feature.

    Also provide a new tracepoint_ptr_defer() static inline to
    encapsulate deferencing this type rather than duplicate code and
    ugly idefs within the for_each_tracepoint_range() implementation.

    This issue appears in 4.19-rc kernels, and should ideally be fixed
    before the end of the rc cycle.

    Acked-by: Ard Biesheuvel
    Acked-by: Jessica Yu
    Link: http://lkml.kernel.org/r/20181013191050.22389-1-mathieu.desnoyers@efficios.com
    Link: http://lkml.kernel.org/r/20180704083651.24360-7-ard.biesheuvel@linaro.org
    Cc: Michael Ellerman
    Cc: Ingo Molnar
    Cc: Ard Biesheuvel
    Cc: Arnd Bergmann
    Cc: Benjamin Herrenschmidt
    Cc: Bjorn Helgaas
    Cc: Catalin Marinas
    Cc: James Morris
    Cc: James Morris
    Cc: Josh Poimboeuf
    Cc: Kees Cook
    Cc: Nicolas Pitre
    Cc: Paul Mackerras
    Cc: Petr Mladek
    Cc: Russell King
    Cc: "Serge E. Hallyn"
    Cc: Sergey Senozhatsky
    Cc: Thomas Garnier
    Cc: Thomas Gleixner
    Cc: Will Deacon
    Cc: Andrew Morton
    Cc: Linus Torvalds
    Cc: Greg Kroah-Hartman
    Signed-off-by: Mathieu Desnoyers
    Signed-off-by: Steven Rostedt (VMware)

    Mathieu Desnoyers
     

05 Sep, 2018

1 commit

  • Borislav reported the following splat:

    =============================
    WARNING: suspicious RCU usage
    4.19.0-rc1+ #1 Not tainted
    -----------------------------
    ./include/linux/rcupdate.h:631 rcu_read_lock() used illegally while idle!
    other info that might help us debug this:

    RCU used illegally from idle CPU!
    rcu_scheduler_active = 2, debug_locks = 1
    RCU used illegally from extended quiescent state!
    1 lock held by swapper/0/0:
    #0: 000000004557ee0e (rcu_read_lock){....}, at: perf_event_output_forward+0x0/0x130

    stack backtrace:
    CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.19.0-rc1+ #1
    Hardware name: LENOVO 2320CTO/2320CTO, BIOS G2ET86WW (2.06 ) 11/13/2012
    Call Trace:
    dump_stack+0x85/0xcb
    perf_event_output_forward+0xf6/0x130
    __perf_event_overflow+0x52/0xe0
    perf_swevent_overflow+0x91/0xb0
    perf_tp_event+0x11a/0x350
    ? find_held_lock+0x2d/0x90
    ? __lock_acquire+0x2ce/0x1350
    ? __lock_acquire+0x2ce/0x1350
    ? retint_kernel+0x2d/0x2d
    ? find_held_lock+0x2d/0x90
    ? tick_nohz_get_sleep_length+0x83/0xb0
    ? perf_trace_cpu+0xbb/0xd0
    ? perf_trace_buf_alloc+0x5a/0xa0
    perf_trace_cpu+0xbb/0xd0
    cpuidle_enter_state+0x185/0x340
    do_idle+0x1eb/0x260
    cpu_startup_entry+0x5f/0x70
    start_kernel+0x49b/0x4a6
    secondary_startup_64+0xa4/0xb0

    This is due to the tracepoints moving to SRCU usage which does not require
    RCU to be "watching". But perf uses these tracepoints with RCU and expects
    it to be. Hence, we still need to add in the rcu_irq_enter/exit_irqson()
    calls for "rcuidle" tracepoints. This is a temporary fix until we have SRCU
    working in NMI context, and then perf can be converted to use that instead
    of normal RCU.

    Link: http://lkml.kernel.org/r/20180904162611.6a120068@gandalf.local.home

    Cc: x86-ml
    Cc: Peter Zijlstra
    Reported-by: Borislav Petkov
    Tested-by: Borislav Petkov
    Reviewed-by: "Paul E. McKenney"
    Fixes: e6753f23d961d ("tracepoint: Make rcuidle tracepoint callers use SRCU")
    Signed-off-by: Steven Rostedt (VMware)

    Steven Rostedt (VMware)
     

23 Aug, 2018

1 commit

  • To avoid the need for relocating absolute references to tracepoint
    structures at boot time when running relocatable kernels (which may
    take a disproportionate amount of space), add the option to emit
    these tables as relative references instead.

    Link: http://lkml.kernel.org/r/20180704083651.24360-7-ard.biesheuvel@linaro.org
    Acked-by: Michael Ellerman
    Acked-by: Ingo Molnar
    Acked-by: Steven Rostedt (VMware)
    Signed-off-by: Ard Biesheuvel
    Cc: Arnd Bergmann
    Cc: Benjamin Herrenschmidt
    Cc: Bjorn Helgaas
    Cc: Catalin Marinas
    Cc: James Morris
    Cc: James Morris
    Cc: Jessica Yu
    Cc: Josh Poimboeuf
    Cc: Kees Cook
    Cc: Nicolas Pitre
    Cc: Paul Mackerras
    Cc: Petr Mladek
    Cc: Russell King
    Cc: "Serge E. Hallyn"
    Cc: Sergey Senozhatsky
    Cc: Thomas Garnier
    Cc: Thomas Gleixner
    Cc: Will Deacon
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ard Biesheuvel
     

31 Jul, 2018

1 commit

  • In recent tests with IRQ on/off tracepoints, a large performance
    overhead ~10% is noticed when running hackbench. This is root caused to
    calls to rcu_irq_enter_irqson and rcu_irq_exit_irqson from the
    tracepoint code. Following a long discussion on the list [1] about this,
    we concluded that srcu is a better alternative for use during rcu idle.
    Although it does involve extra barriers, its lighter than the sched-rcu
    version which has to do additional RCU calls to notify RCU idle about
    entry into RCU sections.

    In this patch, we change the underlying implementation of the
    trace_*_rcuidle API to use SRCU. This has shown to improve performance
    alot for the high frequency irq enable/disable tracepoints.

    Test: Tested idle and preempt/irq tracepoints.

    Here are some performance numbers:

    With a run of the following 30 times on a single core x86 Qemu instance
    with 1GB memory:
    hackbench -g 4 -f 2 -l 3000

    Completion times in seconds. CONFIG_PROVE_LOCKING=y.

    No patches (without this series)
    Mean: 3.048
    Median: 3.025
    Std Dev: 0.064

    With Lockdep using irq tracepoints with RCU implementation:
    Mean: 3.451 (-11.66 %)
    Median: 3.447 (-12.22%)
    Std Dev: 0.049

    With Lockdep using irq tracepoints with SRCU implementation (this series):
    Mean: 3.020 (I would consider the improvement against the "without
    this series" case as just noise).
    Median: 3.013
    Std Dev: 0.033

    [1] https://patchwork.kernel.org/patch/10344297/

    [remove rcu_read_lock_sched_notrace as its the equivalent of
    preempt_disable_notrace and is unnecessary to call in tracepoint code]
    Link: http://lkml.kernel.org/r/20180730222423.196630-3-joel@joelfernandes.org

    Cleaned-up-by: Peter Zijlstra
    Acked-by: Peter Zijlstra
    Reviewed-by: Mathieu Desnoyers
    Signed-off-by: Joel Fernandes (Google)
    [ Simplified WARN_ON_ONCE() ]
    Signed-off-by: Steven Rostedt (VMware)

    Joel Fernandes (Google)
     

16 Jun, 2018

1 commit


28 Nov, 2017

1 commit

  • Now that the irq path uses the rcu_nmi_{enter,exit}() algorithm,
    rcu_irq_enter() and rcu_irq_exit() may be used from any context. There is
    thus no need for rcu_irq_enter_disabled() and for the checks using it.
    This commit therefore eliminates rcu_irq_enter_disabled().

    Signed-off-by: Paul E. McKenney

    Paul E. McKenney
     

14 Jun, 2017

2 commits


11 Apr, 2017

1 commit

  • Stack tracing discovered that there's a small location inside the RCU
    infrastructure where calling rcu_irq_enter() does not work. As trace events
    use rcu_irq_enter() it must make sure that it is functionable. A check
    against rcu_irq_enter_disabled() is added with a WARN_ON_ONCE() as no trace
    event should ever be used in that part of RCU. If the warning is triggered,
    then the trace event is ignored.

    Restructure the __DO_TRACE() a bit to get rid of the prercu and postrcu,
    and just have an rcucheck that does the work from within the _DO_TRACE()
    macro. gcc optimization will compile out the rcucheck=0 case.

    Link: http://lkml.kernel.org/r/20170405093207.404f8deb@gandalf.local.home

    Acked-by: Mathieu Desnoyers
    Acked-by: Paul E. McKenney
    Signed-off-by: Steven Rostedt (VMware)

    Steven Rostedt (VMware)
     

09 Dec, 2016

1 commit

  • Some tracepoints have a registration function that gets enabled when the
    tracepoint is enabled. There may be cases that the registraction function
    must fail (for example, can't allocate enough memory). In this case, the
    tracepoint should also fail to register, otherwise the user would not know
    why the tracepoint is not working.

    Cc: David Howells
    Cc: Seiji Aguchi
    Cc: Anton Blanchard
    Cc: Mathieu Desnoyers
    Signed-off-by: Steven Rostedt

    Steven Rostedt (Red Hat)
     

10 Mar, 2016

1 commit

  • Commit f37755490fe9b ("tracepoints: Do not trace when cpu is offline") added
    a check to make sure that tracepoints only get called when the cpu is
    online, as it uses rcu_read_lock_sched() for protection.

    Commit 3a630178fd5f3 ("tracing: generate RCU warnings even when tracepoints
    are disabled") added lockdep checks (including rcu checks) for events that
    are not enabled to catch possible RCU issues that would only be triggered if
    a trace event was enabled. Commit f37755490fe9b only stopped the warnings
    when the trace event was enabled but did not prevent warnings if the trace
    event was called when disabled.

    To fix this, the cpu online check is moved to where the condition is added
    to the trace event. This will place the cpu online check in all places that
    it may be used now and in the future.

    Cc: stable@vger.kernel.org # v3.18+
    Fixes: f37755490fe9b ("tracepoints: Do not trace when cpu is offline")
    Fixes: 3a630178fd5f3 ("tracing: generate RCU warnings even when tracepoints are disabled")
    Reported-by: Sudeep Holla
    Tested-by: Sudeep Holla
    Signed-off-by: Steven Rostedt

    Steven Rostedt (Red Hat)
     

16 Feb, 2016

1 commit

  • The tracepoint infrastructure uses RCU sched protection to enable and
    disable tracepoints safely. There are some instances where tracepoints are
    used in infrastructure code (like kfree()) that get called after a CPU is
    going offline, and perhaps when it is coming back online but hasn't been
    registered yet.

    This can probuce the following warning:

    [ INFO: suspicious RCU usage. ]
    4.4.0-00006-g0fe53e8-dirty #34 Tainted: G S
    -------------------------------
    include/trace/events/kmem.h:141 suspicious rcu_dereference_check() usage!

    other info that might help us debug this:

    RCU used illegally from offline CPU! rcu_scheduler_active = 1, debug_locks = 1
    no locks held by swapper/8/0.

    stack backtrace:
    CPU: 8 PID: 0 Comm: swapper/8 Tainted: G S 4.4.0-00006-g0fe53e8-dirty #34
    Call Trace:
    [c0000005b76c78d0] [c0000000008b9540] .dump_stack+0x98/0xd4 (unreliable)
    [c0000005b76c7950] [c00000000010c898] .lockdep_rcu_suspicious+0x108/0x170
    [c0000005b76c79e0] [c00000000029adc0] .kfree+0x390/0x440
    [c0000005b76c7a80] [c000000000055f74] .destroy_context+0x44/0x100
    [c0000005b76c7b00] [c0000000000934a0] .__mmdrop+0x60/0x150
    [c0000005b76c7b90] [c0000000000e3ff0] .idle_task_exit+0x130/0x140
    [c0000005b76c7c20] [c000000000075804] .pseries_mach_cpu_die+0x64/0x310
    [c0000005b76c7cd0] [c000000000043e7c] .cpu_die+0x3c/0x60
    [c0000005b76c7d40] [c0000000000188d8] .arch_cpu_idle_dead+0x28/0x40
    [c0000005b76c7db0] [c000000000101e6c] .cpu_startup_entry+0x50c/0x560
    [c0000005b76c7ed0] [c000000000043bd8] .start_secondary+0x328/0x360
    [c0000005b76c7f90] [c000000000008a6c] start_secondary_prolog+0x10/0x14

    This warning is not a false positive either. RCU is not protecting code that
    is being executed while the CPU is offline.

    Instead of playing "whack-a-mole(TM)" and adding conditional statements to
    the tracepoints we find that are used in this instance, simply add a
    cpu_online() test to the tracepoint code where the tracepoint will be
    ignored if the CPU is offline.

    Use of raw_smp_processor_id() is fine, as there should never be a case where
    the tracepoint code goes from running on a CPU that is online and suddenly
    gets migrated to a CPU that is offline.

    Link: http://lkml.kernel.org/r/1455387773-4245-1-git-send-email-kda@linux-powerpc.org

    Reported-by: Denis Kirjanov
    Fixes: 97e1c18e8d17b ("tracing: Kernel Tracepoints")
    Cc: stable@vger.kernel.org # v2.6.28+
    Signed-off-by: Steven Rostedt

    Steven Rostedt (Red Hat)
     

13 Jan, 2016

1 commit

  • Pull tracing updates from Steven Rostedt:
    "Not much new with tracing for this release. Mostly just clean ups and
    minor fixes.

    Here's what else is new:

    - A new TRACE_EVENT_FN_COND macro, combining both _FN and _COND for
    those that want both.

    - New selftest to test the instance create and delete

    - Better debug output when ftrace fails"

    * tag 'trace-v4.5' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace: (24 commits)
    ftrace: Fix the race between ftrace and insmod
    ftrace: Add infrastructure for delayed enabling of module functions
    x86: ftrace: Fix the comments for ftrace_modify_code_direct()
    tracing: Fix comment to use tracing_on over tracing_enable
    metag: ftrace: Fix the comments for ftrace_modify_code
    sh: ftrace: Fix the comments for ftrace_modify_code()
    ia64: ftrace: Fix the comments for ftrace_modify_code()
    ftrace: Clean up ftrace_module_init() code
    ftrace: Join functions ftrace_module_init() and ftrace_init_module()
    tracing: Introduce TRACE_EVENT_FN_COND macro
    tracing: Use seq_buf_used() in seq_buf_to_user() instead of len
    bpf: Constify bpf_verifier_ops structure
    ftrace: Have ftrace_ops_get_func() handle RCU and PER_CPU flags too
    ftrace: Remove use of control list and ops
    ftrace: Fix output of enabled_functions for showing tramp
    ftrace: Fix a typo in comment
    ftrace: Show all tramps registered to a record on ftrace_bug()
    ftrace: Add variable ftrace_expected for archs to show expected code
    ftrace: Add new type to distinguish what kind of ftrace_bug()
    tracing: Update cond flag when enabling or disabling a trigger
    ...

    Linus Torvalds
     

12 Jan, 2016

1 commit

  • Pull perf updates from Ingo Molnar:
    "Kernel side changes:

    - Intel Knights Landing support. (Harish Chegondi)

    - Intel Broadwell-EP uncore PMU support. (Kan Liang)

    - Core code improvements. (Peter Zijlstra.)

    - Event filter, LBR and PEBS fixes. (Stephane Eranian)

    - Enable cycles:pp on Intel Atom. (Stephane Eranian)

    - Add cycles:ppp support for Skylake. (Andi Kleen)

    - Various x86 NMI overhead optimizations. (Andi Kleen)

    - Intel PT enhancements. (Takao Indoh)

    - AMD cache events fix. (Vince Weaver)

    Tons of tooling changes:

    - Show random perf tool tips in the 'perf report' bottom line
    (Namhyung Kim)

    - perf report now defaults to --group if the perf.data file has
    grouped events, try it with:

    # perf record -e '{cycles,instructions}' -a sleep 1
    [ perf record: Woken up 1 times to write data ]
    [ perf record: Captured and wrote 1.093 MB perf.data (1247 samples) ]
    # perf report
    # Samples: 1K of event 'anon group { cycles, instructions }'
    # Event count (approx.): 1955219195
    #
    # Overhead Command Shared Object Symbol

    2.86% 0.22% swapper [kernel.kallsyms] [k] intel_idle
    1.05% 0.33% firefox libxul.so [.] js::SetObjectElement
    1.05% 0.00% kworker/0:3 [kernel.kallsyms] [k] gen6_ring_get_seqno
    0.88% 0.17% chrome chrome [.] 0x0000000000ee27ab
    0.65% 0.86% firefox libxul.so [.] js::ValueToId
    0.64% 0.23% JS Helper libxul.so [.] js::SplayTree::splay
    0.62% 1.27% firefox libxul.so [.] js::GetIterator
    0.61% 1.74% firefox libxul.so [.] js::NativeSetProperty
    0.61% 0.31% firefox libxul.so [.] js::SetPropertyByDefining

    - Introduce the 'perf stat record/report' workflow:

    Generate perf.data files from 'perf stat', to tap into the
    scripting capabilities perf has instead of defining a 'perf stat'
    specific scripting support to calculate event ratios, etc.

    Simple example:

    $ perf stat record -e cycles usleep 1

    Performance counter stats for 'usleep 1':

    1,134,996 cycles

    0.000670644 seconds time elapsed

    $ perf stat report

    Performance counter stats for '/home/acme/bin/perf stat record -e cycles usleep 1':

    1,134,996 cycles

    0.000670644 seconds time elapsed

    $

    It generates PERF_RECORD_ userspace records to store the details:

    $ perf report -D | grep PERF_RECORD
    0xf0 [0x28]: PERF_RECORD_THREAD_MAP nr: 1 thread: 27637
    0x118 [0x12]: PERF_RECORD_CPU_MAP nr: 1 cpu: 65535
    0x12a [0x40]: PERF_RECORD_STAT_CONFIG
    0x16a [0x30]: PERF_RECORD_STAT
    -1 -1 0x19a [0x40]: PERF_RECORD_MMAP -1/0: [0xffffffff81000000(0x1f000000) @ 0xffffffff81000000]: x [kernel.kallsyms]_text
    0x1da [0x18]: PERF_RECORD_STAT_ROUND
    [acme@ssdandy linux]$

    An effort was made to make perf.data files generated like this to
    not generate cryptic messages when processed by older tools.

    The 'perf script' bits need rebasing, will go up later.

    - Make command line options always available, even when they depend
    on some feature being enabled, warning the user about use of such
    options (Wang Nan)

    - Support hw breakpoint events (mem:0xAddress) in the default output
    mode in 'perf script' (Wang Nan)

    - Fixes and improvements for supporting annotating ARM binaries,
    support ARM call and jump instructions, more work needed to have
    arch specific stuff separated into tools/perf/arch/*/annotate/
    (Russell King)

    - Add initial 'perf config' command, for now just with a --list
    command to the contents of the configuration file in use and a
    basic man page describing its format, commands for doing edits and
    detailed documentation are being reviewed and proof-read. (Taeung
    Song)

    - Allows BPF scriptlets specify arguments to be fetched using DWARF
    info, using a prologue generated at compile/build time (He Kuang,
    Wang Nan)

    - Allow attaching BPF scriptlets to module symbols (Wang Nan)

    - Allow attaching BPF scriptlets to userspace code using uprobe (Wang
    Nan)

    - BPF programs now can specify 'perf probe' tunables via its section
    name, separating key=val values using semicolons (Wang Nan)

    Testing some of these new BPF features:

    Use case: get callchains when receiving SSL packets, filter then in the
    kernel, at arbitrary place.

    # cat ssl.bpf.c
    #define SEC(NAME) __attribute__((section(NAME), used))

    struct pt_regs;

    SEC("func=__inet_lookup_established hnum")
    int func(struct pt_regs *ctx, int err, unsigned short port)
    {
    return err == 0 && port == 443;
    }

    char _license[] SEC("license") = "GPL";
    int _version SEC("version") = LINUX_VERSION_CODE;
    #
    # perf record -a -g -e ssl.bpf.c
    ^C[ perf record: Woken up 1 times to write data ]
    [ perf record: Captured and wrote 0.787 MB perf.data (3 samples) ]
    # perf script | head -30
    swapper 0 [000] 58783.268118: perf_bpf_probe:func: (ffffffff816a0f60) hnum=0x1bb
    8a0f61 __inet_lookup_established (/lib/modules/4.3.0+/build/vmlinux)
    896def ip_rcv_finish (/lib/modules/4.3.0+/build/vmlinux)
    8976c2 ip_rcv (/lib/modules/4.3.0+/build/vmlinux)
    855eba __netif_receive_skb_core (/lib/modules/4.3.0+/build/vmlinux)
    8565d8 __netif_receive_skb (/lib/modules/4.3.0+/build/vmlinux)
    8572a8 process_backlog (/lib/modules/4.3.0+/build/vmlinux)
    856b11 net_rx_action (/lib/modules/4.3.0+/build/vmlinux)
    2a284b __do_softirq (/lib/modules/4.3.0+/build/vmlinux)
    2a2ba3 irq_exit (/lib/modules/4.3.0+/build/vmlinux)
    96b7a4 do_IRQ (/lib/modules/4.3.0+/build/vmlinux)
    969807 ret_from_intr (/lib/modules/4.3.0+/build/vmlinux)
    2dede5 cpu_startup_entry (/lib/modules/4.3.0+/build/vmlinux)
    95d5bc rest_init (/lib/modules/4.3.0+/build/vmlinux)
    1163ffa start_kernel ([kernel.vmlinux].init.text)
    11634d7 x86_64_start_reservations ([kernel.vmlinux].init.text)
    1163623 x86_64_start_kernel ([kernel.vmlinux].init.text)

    qemu-system-x86 9178 [003] 58785.792417: perf_bpf_probe:func: (ffffffff816a0f60) hnum=0x1bb
    8a0f61 __inet_lookup_established (/lib/modules/4.3.0+/build/vmlinux)
    896def ip_rcv_finish (/lib/modules/4.3.0+/build/vmlinux)
    8976c2 ip_rcv (/lib/modules/4.3.0+/build/vmlinux)
    855eba __netif_receive_skb_core (/lib/modules/4.3.0+/build/vmlinux)
    8565d8 __netif_receive_skb (/lib/modules/4.3.0+/build/vmlinux)
    856660 netif_receive_skb_internal (/lib/modules/4.3.0+/build/vmlinux)
    8566ec netif_receive_skb_sk (/lib/modules/4.3.0+/build/vmlinux)
    430a br_handle_frame_finish ([bridge])
    48bc br_handle_frame ([bridge])
    855f44 __netif_receive_skb_core (/lib/modules/4.3.0+/build/vmlinux)
    8565d8 __netif_receive_skb (/lib/modules/4.3.0+/build/vmlinux)
    #

    - Use 'perf probe' various options to list functions, see what
    variables can be collected at any given point, experiment first
    collecting without a filter, then filter, use it together with
    'perf trace', 'perf top', with or without callchains, if it
    explodes, please tell us!

    - Introduce a new callchain mode: "folded", that will list per line
    representations of all callchains for a give histogram entry,
    facilitating 'perf report' output processing by other tools, such
    as Brendan Gregg's flamegraph tools (Namhyung Kim)

    E.g:

    # perf report | grep -v ^# | head
    18.37% 0.00% swapper [kernel.kallsyms] [k] cpu_startup_entry
    |
    ---cpu_startup_entry
    |
    |--12.07%--start_secondary
    |
    --6.30%--rest_init
    start_kernel
    x86_64_start_reservations
    x86_64_start_kernel
    #

    Becomes, in "folded" mode:

    # perf report -g folded | grep -v ^# | head -5
    18.37% 0.00% swapper [kernel.kallsyms] [k] cpu_startup_entry
    12.07% cpu_startup_entry;start_secondary
    6.30% cpu_startup_entry;rest_init;start_kernel;x86_64_start_reservations;x86_64_start_kernel
    16.90% 0.00% swapper [kernel.kallsyms] [k] call_cpuidle
    11.23% call_cpuidle;cpu_startup_entry;start_secondary
    5.67% call_cpuidle;cpu_startup_entry;rest_init;start_kernel;x86_64_start_reservations;x86_64_start_kernel
    16.90% 0.00% swapper [kernel.kallsyms] [k] cpuidle_enter
    11.23% cpuidle_enter;call_cpuidle;cpu_startup_entry;start_secondary
    5.67% cpuidle_enter;call_cpuidle;cpu_startup_entry;rest_init;start_kernel;x86_64_start_reservations;x86_64_start_kernel
    15.12% 0.00% swapper [kernel.kallsyms] [k] cpuidle_enter_state
    #

    The user can also select one of "count", "period" or "percent" as
    the first column.

    ... and lots of infrastructure enhancements, plus fixes and other
    changes, features I failed to list - see the shortlog and the git log
    for details"

    * 'perf-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (271 commits)
    perf evlist: Add --trace-fields option to show trace fields
    perf record: Store data mmaps for dwarf unwind
    perf libdw: Check for mmaps also in MAP__VARIABLE tree
    perf unwind: Check for mmaps also in MAP__VARIABLE tree
    perf unwind: Use find_map function in access_dso_mem
    perf evlist: Remove perf_evlist__(enable|disable)_event functions
    perf evlist: Make perf_evlist__open() open evsels with their cpus and threads (like perf record does)
    perf report: Show random usage tip on the help line
    perf hists: Export a couple of hist functions
    perf diff: Use perf_hpp__register_sort_field interface
    perf tools: Add overhead/overhead_children keys defaults via string
    perf tools: Remove list entry from struct sort_entry
    perf tools: Include all tools/lib directory for tags/cscope/TAGS targets
    perf script: Align event name properly
    perf tools: Add missing headers in perf's MANIFEST
    perf tools: Do not show trace command if it's not compiled in
    perf report: Change default to use event group view
    perf top: Decay periods in callchains
    tools lib: Move bitmap.[ch] from tools/perf/ to tools/{lib,include}/
    tools lib: Sync tools/lib/find_bit.c with the kernel
    ...

    Linus Torvalds
     

24 Dec, 2015

1 commit

  • TRACE_EVENT_FN can't be used in some circumstances
    like invoking trace functions from offlined CPU due
    to RCU usage.

    This patch adds the TRACE_EVENT_FN_COND macro
    to make such trace points conditional.

    Link: http://lkml.kernel.org/r/1450124286-4822-1-git-send-email-kda@linux-powerpc.org

    Signed-off-by: Denis Kirjanov
    Signed-off-by: Steven Rostedt

    Denis Kirjanov
     

08 Dec, 2015

1 commit

  • This commit replaces a local_irq_save()/local_irq_restore() pair with
    a lockdep assertion that interrupts are already disabled. This should
    remove the corresponding overhead from the interrupt entry/exit fastpaths.

    This change was inspired by the fact that Iftekhar Ahmed's mutation
    testing showed that removing rcu_irq_enter()'s call to local_ird_restore()
    had no effect, which might indicate that interrupts were always enabled
    anyway.

    Signed-off-by: Paul E. McKenney

    Paul E. McKenney
     

06 Dec, 2015

1 commit

  • Steven recommended open coding access to tracepoint->key to add
    trace points to headers. Unfortunately this is difficult for some
    headers (such as x86 asm/msr.h) because including tracepoint.h
    includes so many other headers that it causes include loops.
    The main problem is the include of linux/rcupdate.h, which
    pulls in a lot of other headers. The rcu header is only needed
    when actually defining trace points.

    Move the struct tracepoint into a separate tracepoint-defs.h
    header that can be included without pulling in all of RCU.

    Signed-off-by: Andi Kleen
    Signed-off-by: Peter Zijlstra (Intel)
    Acked-by: Steven Rostedt
    Cc: Arnaldo Carvalho de Melo
    Cc: Jiri Olsa
    Cc: Linus Torvalds
    Cc: Mike Galbraith
    Cc: Peter Zijlstra
    Cc: Stephane Eranian
    Cc: Thomas Gleixner
    Cc: Vince Weaver
    Link: http://lkml.kernel.org/r/1449018060-1742-2-git-send-email-andi@firstfloor.org
    Signed-off-by: Ingo Molnar

    Andi Kleen
     

03 Nov, 2015

1 commit

  • The documentation on top of __DECLARE_TRACE() does not match its
    implementation since the condition check has been added to the
    RCU lockdep checks. Update the documentation to match its
    implementation.

    Link: http://lkml.kernel.org/r/1446504164-21563-1-git-send-email-mathieu.desnoyers@efficios.com

    CC: Dave Hansen
    Fixes: a05d59a56733 "tracing: Add condition check to RCU lockdep checks"
    Signed-off-by: Mathieu Desnoyers
    Signed-off-by: Steven Rostedt

    Mathieu Desnoyers
     

26 Oct, 2015

1 commit

  • In order to guarantee that a probe will be called before other probes that
    are attached to a tracepoint, there needs to be a mechanism to provide
    priority of one probe over the others.

    Adding a prio field to the struct tracepoint_func, which lets the probes be
    sorted by the priority set in the structure. If no priority is specified,
    then a priority of 10 is given (this is a macro, and perhaps may be changed
    in the future).

    Now probes may be added to affect other probes that are attached to a
    tracepoint with a guaranteed order.

    One use case would be to allow tracing of tracepoints be able to filter by
    pid. A special (higher priority probe) may be added to the sched_switch
    tracepoint and set the necessary flags of the other tracepoints to notify
    them if they should be traced or not. In case a tracepoint is enabled at the
    sched_switch tracepoint too, the order of the two are not random.

    Cc: Mathieu Desnoyers
    Signed-off-by: Steven Rostedt

    Steven Rostedt (Red Hat)
     

21 Oct, 2015

1 commit

  • Allow a trace events header file to disable compilation of its
    trace events by defining the preprocessor macro NOTRACE.

    This could be done, for example, according to a Kconfig option.

    Link: http://lkml.kernel.org/r/1438432079-11704-3-git-send-email-tal.shorer@gmail.com

    Signed-off-by: Tal Shorer
    Signed-off-by: Steven Rostedt

    Tal Shorer
     

08 Apr, 2015

1 commit

  • Several tracepoints use the helper functions __print_symbolic() or
    __print_flags() and pass in enums that do the mapping between the
    binary data stored and the value to print. This works well for reading
    the ASCII trace files, but when the data is read via userspace tools
    such as perf and trace-cmd, the conversion of the binary value to a
    human string format is lost if an enum is used, as userspace does not
    have access to what the ENUM is.

    For example, the tracepoint trace_tlb_flush() has:

    __print_symbolic(REC->reason,
    { TLB_FLUSH_ON_TASK_SWITCH, "flush on task switch" },
    { TLB_REMOTE_SHOOTDOWN, "remote shootdown" },
    { TLB_LOCAL_SHOOTDOWN, "local shootdown" },
    { TLB_LOCAL_MM_SHOOTDOWN, "local mm shootdown" })

    Which maps the enum values to the strings they represent. But perf and
    trace-cmd do no know what value TLB_LOCAL_MM_SHOOTDOWN is, and would
    not be able to map it.

    With TRACE_DEFINE_ENUM(), developers can place these in the event header
    files and ftrace will convert the enums to their values:

    By adding:

    TRACE_DEFINE_ENUM(TLB_FLUSH_ON_TASK_SWITCH);
    TRACE_DEFINE_ENUM(TLB_REMOTE_SHOOTDOWN);
    TRACE_DEFINE_ENUM(TLB_LOCAL_SHOOTDOWN);
    TRACE_DEFINE_ENUM(TLB_LOCAL_MM_SHOOTDOWN);

    $ cat /sys/kernel/debug/tracing/events/tlb/tlb_flush/format
    [...]
    __print_symbolic(REC->reason,
    { 0, "flush on task switch" },
    { 1, "remote shootdown" },
    { 2, "local shootdown" },
    { 3, "local mm shootdown" })

    The above is what userspace expects to see, and tools do not need to
    be modified to parse them.

    Link: http://lkml.kernel.org/r/20150403013802.220157513@goodmis.org

    Cc: Guilherme Cox
    Cc: Tony Luck
    Cc: Xie XiuQi
    Acked-by: Namhyung Kim
    Reviewed-by: Masami Hiramatsu
    Tested-by: Masami Hiramatsu
    Signed-off-by: Steven Rostedt

    Steven Rostedt (Red Hat)
     

08 Feb, 2015

1 commit

  • The trace_tlb_flush() tracepoint can be called when a CPU is going offline.
    When a CPU is offline, RCU is no longer watching that CPU and since the
    tracepoint is protected by RCU, it must not be called. To prevent the
    tlb_flush tracepoint from being called when the CPU is offline, it was
    converted to a TRACE_EVENT_CONDITION where the condition checks if the
    CPU is online before calling the tracepoint.

    Unfortunately, this was not enough to stop lockdep from complaining about
    it. Even though the RCU protected code of the tracepoint will never be
    called, the condition is hidden within the tracepoint, and even though the
    condition prevents RCU code from being called, the lockdep checks are
    outside the tracepoint (this is to test tracepoints even when they are not
    enabled).

    Even though tracepoints should be checked to be RCU safe when they are not
    enabled, the condition should still be considered when checking RCU.

    Link: http://lkml.kernel.org/r/CA+icZUUGiGDoL5NU8RuxKzFjoLjEKRtUWx=JB8B9a0EQv-eGzQ@mail.gmail.com

    Fixes: 3a630178fd5f "tracing: generate RCU warnings even when tracepoints are disabled"
    Cc: stable@vger.kernel.org # 3.18+
    Acked-by: Dave Hansen
    Reported-by: Sedat Dilek
    Tested-by: Sedat Dilek
    Signed-off-by: Steven Rostedt

    Steven Rostedt (Red Hat)
     

10 Sep, 2014

1 commit

  • Dave Jones reported seeing a bug from one of my TLB tracepoints:

    http://lkml.kernel.org/r/20140806181801.GA4605@redhat.com

    I've been running these patches for months and never saw this.
    But, a big chunk of my testing, especially with all the debugging
    enabled, was in a vm where intel_idle doesn't work. On the
    systems where I was using intel_idle, I never had lockdep enabled
    and this tracepoint on at the same time.

    This patch ensures that whenever we have lockdep available, we do
    _some_ RCU activity at the site of the tracepoint, despite
    whether the tracepoint's condition matches or even if the
    tracepoint itself is completely disabled. This is a bit of a
    hack, but it is pretty self-contained.

    I confirmed that with this patch plus lockdep I get the same
    splat as Dave Jones did, but without enabling the tracepoint
    explicitly.

    Link: http://lkml.kernel.org/p/20140807175204.C257CAC5@viggo.jf.intel.com

    Signed-off-by: Dave Hansen
    Cc: Dave Hansen
    Cc: Dave Jones ,
    Cc: paulmck@linux.vnet.ibm.com
    Cc: Ingo Molnar
    Signed-off-by: Steven Rostedt

    Dave Hansen
     

08 Aug, 2014

1 commit

  • When CONFIG_TRACING is not enabled, there's no reason to save the trace
    strings either by the linker or as a static variable that can be
    referenced later. Simply pass back the string that is given to
    tracepoint_string().

    Had to move the define to include/linux/tracepoint.h so that it is still
    visible when CONFIG_TRACING is not set.

    Link: http://lkml.kernel.org/p/1406318733-26754-2-git-send-email-nicolas.pitre@linaro.org

    Suggested-by: Nicolas Pitre
    Signed-off-by: Steven Rostedt

    Steven Rostedt
     

08 May, 2014

1 commit

  • There are some code paths in the kernel that need to do some preparations
    before it calls a tracepoint. As that code is worthless overhead when
    the tracepoint is not enabled, it would be prudent to have that code
    only run when the tracepoint is active. To accomplish this, all tracepoints
    now get a static inline function called "trace__enabled()"
    which returns true when the tracepoint is enabled and false otherwise.

    As an added bonus, that function uses the static_key of the tracepoint
    such that no branch is needed.

    if (trace_mytracepoint_enabled()) {
    arg = process_tp_arg();
    trace_mytracepoint(arg);
    }

    Will keep the "process_tp_arg()" (which may be expensive to run) from
    being executed when the tracepoint isn't enabled.

    It's best to encapsulate the tracepoint itself in the if statement
    just to keep races. For example, if you had:

    if (trace_mytracepoint_enabled())
    arg = process_tp_arg();
    trace_mytracepoint(arg);

    There's a chance that the tracepoint could be enabled just after the
    if statement, and arg will be undefined when calling the tracepoint.

    Link: http://lkml.kernel.org/r/20140506094407.507b6435@gandalf.local.home

    Acked-by: Mathieu Desnoyers
    Signed-off-by: Steven Rostedt

    Steven Rostedt (Red Hat)
     

09 Apr, 2014

3 commits

  • Fix the following sparse warnings:

    CHECK kernel/tracepoint.c
    kernel/tracepoint.c:184:18: warning: incorrect type in assignment (different address spaces)
    kernel/tracepoint.c:184:18: expected struct tracepoint_func *tp_funcs
    kernel/tracepoint.c:184:18: got struct tracepoint_func [noderef] *funcs
    kernel/tracepoint.c:216:18: warning: incorrect type in assignment (different address spaces)
    kernel/tracepoint.c:216:18: expected struct tracepoint_func *tp_funcs
    kernel/tracepoint.c:216:18: got struct tracepoint_func [noderef] *funcs
    kernel/tracepoint.c:392:24: error: return expression in void function
    CC kernel/tracepoint.o
    kernel/tracepoint.c: In function tracepoint_module_going:
    kernel/tracepoint.c:491:6: warning: symbol 'syscall_regfunc' was not declared. Should it be static?
    kernel/tracepoint.c:508:6: warning: symbol 'syscall_unregfunc' was not declared. Should it be static?

    Link: http://lkml.kernel.org/r/1397049883-28692-1-git-send-email-mathieu.desnoyers@efficios.com

    Signed-off-by: Mathieu Desnoyers
    Signed-off-by: Steven Rostedt

    Mathieu Desnoyers
     
  • Instead of copying the num_tracepoints and tracepoints_ptrs from
    the module structure to the tp_mod structure, which only uses it to
    find the module associated to tracepoints of modules that are coming
    and going, simply copy the pointer to the module struct to the tracepoint
    tp_module structure.

    Also removed un-needed brackets around an if statement.

    Link: http://lkml.kernel.org/r/20140408201705.4dad2c4a@gandalf.local.home

    Acked-by: Mathieu Desnoyers
    Signed-off-by: Steven Rostedt

    Steven Rostedt (Red Hat)
     
  • Register/unregister tracepoint probes with struct tracepoint pointer
    rather than tracepoint name.

    This change, which vastly simplifies tracepoint.c, has been proposed by
    Steven Rostedt. It also removes 8.8kB (mostly of text) to the vmlinux
    size.

    From this point on, the tracers need to pass a struct tracepoint pointer
    to probe register/unregister. A probe can now only be connected to a
    tracepoint that exists. Moreover, tracers are responsible for
    unregistering the probe before the module containing its associated
    tracepoint is unloaded.

    text data bss dec hex filename
    10443444 4282528 10391552 25117524 17f4354 vmlinux.orig
    10434930 4282848 10391552 25109330 17f2352 vmlinux

    Link: http://lkml.kernel.org/r/1396992381-23785-2-git-send-email-mathieu.desnoyers@efficios.com

    CC: Ingo Molnar
    CC: Frederic Weisbecker
    CC: Andrew Morton
    CC: Frank Ch. Eigler
    CC: Johannes Berg
    Signed-off-by: Mathieu Desnoyers
    [ SDR - fixed return val in void func in tracepoint_module_going() ]
    Signed-off-by: Steven Rostedt

    Mathieu Desnoyers
     

04 Apr, 2014

1 commit

  • Pull tracing updates from Steven Rostedt:
    "Most of the changes were largely clean ups, and some documentation.
    But there were a few features that were added:

    Uprobes now work with event triggers and multi buffers and have
    support under ftrace and perf.

    The big feature is that the function tracer can now be used within the
    multi buffer instances. That is, you can now trace some functions in
    one buffer, others in another buffer, all functions in a third buffer
    and so on. They are basically agnostic from each other. This only
    works for the function tracer and not for the function graph trace,
    although you can have the function graph tracer running in the top
    level buffer (or any tracer for that matter) and have different
    function tracing going on in the sub buffers"

    * tag 'trace-3.15' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace: (45 commits)
    tracing: Add BUG_ON when stack end location is over written
    tracepoint: Remove unused API functions
    Revert "tracing: Move event storage for array from macro to standalone function"
    ftrace: Constify ftrace_text_reserved
    tracepoints: API doc update to tracepoint_probe_register() return value
    tracepoints: API doc update to data argument
    ftrace: Fix compilation warning about control_ops_free
    ftrace/x86: BUG when ftrace recovery fails
    ftrace: Warn on error when modifying ftrace function
    ftrace: Remove freelist from struct dyn_ftrace
    ftrace: Do not pass data to ftrace_dyn_arch_init
    ftrace: Pass retval through return in ftrace_dyn_arch_init()
    ftrace: Inline the code from ftrace_dyn_table_alloc()
    ftrace: Cleanup of global variables ftrace_new_pgs and ftrace_update_cnt
    tracing: Evaluate len expression only once in __dynamic_array macro
    tracing: Correctly expand len expressions from __dynamic_array macro
    tracing/module: Replace include of tracepoint.h with jump_label.h in module.h
    tracing: Fix event header migrate.h to include tracepoint.h
    tracing: Fix event header writeback.h to include tracepoint.h
    tracing: Warn if a tracepoint is not set via debugfs
    ...

    Linus Torvalds