Re: lockdep warning in check_flags()

Ingo Molnar
2006-09-11T05:51:17Z

* 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?)]

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