lkml.org 
[lkml]   [2016]   [Apr]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    From
    Subject[PATCH 4.4 164/210] tracing: Have preempt(irqs)off trace preempt disabled functions
    Date
    4.4-stable review patch.  If anyone has any objections, please let me know.

    ------------------

    From: Steven Rostedt (Red Hat) <rostedt@goodmis.org>

    commit cb86e05390debcc084cfdb0a71ed4c5dbbec517d upstream.

    Joel Fernandes reported that the function tracing of preempt disabled
    sections was not being reported when running either the preemptirqsoff or
    preemptoff tracers. This was due to the fact that the function tracer
    callback for those tracers checked if irqs were disabled before tracing. But
    this fails when we want to trace preempt off locations as well.

    Joel explained that he wanted to see funcitons where interrupts are enabled
    but preemption was disabled. The expected output he wanted:

    <...>-2265 1d.h1 3419us : preempt_count_sub <-irq_exit
    <...>-2265 1d..1 3419us : __do_softirq <-irq_exit
    <...>-2265 1d..1 3419us : msecs_to_jiffies <-__do_softirq
    <...>-2265 1d..1 3420us : irqtime_account_irq <-__do_softirq
    <...>-2265 1d..1 3420us : __local_bh_disable_ip <-__do_softirq
    <...>-2265 1..s1 3421us : run_timer_softirq <-__do_softirq
    <...>-2265 1..s1 3421us : hrtimer_run_pending <-run_timer_softirq
    <...>-2265 1..s1 3421us : _raw_spin_lock_irq <-run_timer_softirq
    <...>-2265 1d.s1 3422us : preempt_count_add <-_raw_spin_lock_irq
    <...>-2265 1d.s2 3422us : _raw_spin_unlock_irq <-run_timer_softirq
    <...>-2265 1..s2 3422us : preempt_count_sub <-_raw_spin_unlock_irq
    <...>-2265 1..s1 3423us : rcu_bh_qs <-__do_softirq
    <...>-2265 1d.s1 3423us : irqtime_account_irq <-__do_softirq
    <...>-2265 1d.s1 3423us : __local_bh_enable <-__do_softirq

    There's a comment saying that the irq disabled check is because there's a
    possible race that tracing_cpu may be set when the function is executed. But
    I don't remember that race. For now, I added a check for preemption being
    enabled too to not record the function, as there would be no race if that
    was the case. I need to re-investigate this, as I'm now thinking that the
    tracing_cpu will always be correct. But no harm in keeping the check for
    now, except for the slight performance hit.

    Link: http://lkml.kernel.org/r/1457770386-88717-1-git-send-email-agnel.joel@gmail.com

    Fixes: 5e6d2b9cfa3a "tracing: Use one prologue for the preempt irqs off tracer function tracers"
    Reported-by: Joel Fernandes <agnel.joel@gmail.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

    ---
    kernel/trace/trace_irqsoff.c | 8 ++++++--
    1 file changed, 6 insertions(+), 2 deletions(-)

    --- a/kernel/trace/trace_irqsoff.c
    +++ b/kernel/trace/trace_irqsoff.c
    @@ -109,8 +109,12 @@ static int func_prolog_dec(struct trace_
    return 0;

    local_save_flags(*flags);
    - /* slight chance to get a false positive on tracing_cpu */
    - if (!irqs_disabled_flags(*flags))
    + /*
    + * Slight chance to get a false positive on tracing_cpu,
    + * although I'm starting to think there isn't a chance.
    + * Leave this for now just to be paranoid.
    + */
    + if (!irqs_disabled_flags(*flags) && !preempt_count())
    return 0;

    *data = per_cpu_ptr(tr->trace_buffer.data, cpu);

    \
     
     \ /
      Last update: 2016-04-10 21:21    [W:4.088 / U:0.040 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site