lkml.org 
[lkml]   [2010]   [Apr]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    From
    Subject[PATCH 1/2 v2] lockdep: Fix redundant_hardirqs_on incremented with irqs enabled
    Date
    When a path restore the flags while irqs are already enabled, we
    update the per cpu var redundant_hardirqs_on in a racy fashion
    and debug_atomic_inc() warns about this situation.

    In this particular case, loosing a few hits in a stat is not a big
    deal, so increment it without protection.

    v2: Don't bother with disabling irq, we can miss one count in
    rare situations

    Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
    Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: David Miller <davem@davemloft.net>
    Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    ---
    kernel/lockdep.c | 7 ++++++-
    1 files changed, 6 insertions(+), 1 deletions(-)

    diff --git a/kernel/lockdep.c b/kernel/lockdep.c
    index 78325f8..1b58a1b 100644
    --- a/kernel/lockdep.c
    +++ b/kernel/lockdep.c
    @@ -2298,7 +2298,12 @@ void trace_hardirqs_on_caller(unsigned long ip)
    return;

    if (unlikely(curr->hardirqs_enabled)) {
    - debug_atomic_inc(redundant_hardirqs_on);
    + /*
    + * Neither irq nor preemption are disabled here
    + * so this is racy by nature but loosing one hit
    + * in a stat is not a big deal.
    + */
    + this_cpu_inc(lockdep_stats.redundant_hardirqs_on);
    return;
    }
    /* we'll do an OFF -> ON transition: */
    --
    1.6.2.3


    \
     
     \ /
      Last update: 2010-04-15 23:13    [W:4.698 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site