lkml.org 
[lkml]   [2006]   [Sep]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: lockdep warning in check_flags()
    On Mon, Sep 11, 2006 at 07:43:35AM +0200, Ingo Molnar wrote:
    >
    > * Frederik Deweerdt <deweerdt@free.fr> wrote:
    >
    > > Lockdep issues the following warning:
    > >
    > > [ 16.835268] Freeing unused kernel memory: 260k freed
    > > [ 16.842715] Write protecting the kernel read-only data: 432k
    > > [ 17.796518] BUG: warning at kernel/lockdep.c:2359/check_flags()
    >
    > this warning means that the "soft" and "hard" hardirqs-disabled state
    > got out of sync: the irqtrace tracking code thinks that hardirqs are
    > disabled, while in reality they are enabled. The thing to watch for are
    > new "stii" instructions in entry.S (and other assembly code), without a
    > matching TRACE_HARDIRQS_ON call. [Another, rarer possiblity is NMI code
    > saving/restoring interrupts - do you have NMIs enabled? (are there any
    > NMI counts in /proc/interrupts?)]
    NMIs were disabled. But I've just booted -mm2 and the warning went away.
    Could this be related to the recent pda changes?
    FWIW, I did the bisection (inserting TRACE_HARDIRQS_ON between
    sysenter_past_esp and the cli) and it gave the following result:
    In entry.S:
    310
    311 pushl %eax
    312 CFI_ADJUST_CFA_OFFSET 4
    313 SAVE_ALL
    314 GET_THREAD_INFO(%ebp)
    315
    If I put TRACE_HARDIRQS_ON at line 310, lockdep complains about having
    interrupts enabled and being told to re-enable them. If I put
    TRACE_HARDIRQS_ON at line 315, lockdep goes back to the original
    message.

    Regards,
    Frederik
    >
    > lockdep automatically generates a minimal trace of hardirqs-off
    > state-setting:
    >
    > > [ 17.885839] irq event stamp: 8318
    > > [ 17.892746] hardirqs last enabled at (8317): [<c01032c8>] restore_nocheck+0x12/0x15
    > > [ 17.906778] hardirqs last disabled at (8318): [<c0103203>] sysenter_past_esp+0x6c/0x99
    > > [ 17.921481] softirqs last enabled at (7128): [<c0123cd1>] __do_softirq+0xe9/0xfa
    > > [ 17.936962] softirqs last disabled at (7121): [<c0123d3e>] do_softirq+0x5c/0x60
    >
    > this means that the last registered 'hardirqs off' event was
    > sysenter_past_esp, i.e. the normal sysenter syscall entry code - but
    > nothing re-enabled hardirqs - which is weird, given that you ended up in
    > sys_brk().
    >
    > > I've replaced the DEBUG_LOCKS_WARN_ON by a BUG, and it appears that
    > > the user space program calling sys_brk is hotplug.
    >
    > (ok, i'll enhance the debug printout to include the process name and
    > PID.)
    >
    > Ingo
    > -
    > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    > the body of a message to majordomo@vger.kernel.org
    > More majordomo info at http://vger.kernel.org/majordomo-info.html
    > Please read the FAQ at http://www.tux.org/lkml/
    >
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-09-12 19:17    [W:4.423 / U:0.100 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site