[lkml]   [2006]   [Sep]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: lockdep warning in check_flags()

* Frederik Deweerdt <> 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

> [ 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

> 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

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-09-11 07:55    [W:0.237 / U:37.972 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site