Re: lockdep warning in check_flags()

[Ingo Molnar]

* Frederik Deweerdt <deweerdt@xxxxxxx> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/