Re: lockdep warning in check_flags()

[Frederik Deweerdt <deweerdt@free.fr>]

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