Re: [PATCH] lockdep: annotate i386 apm

[Peter Zijlstra <a.p.zijlstra@chello.nl>]

On Thu, 2006-10-12 at 10:02 +0200, Ingo Molnar wrote:
> * Andrew Morton <akpm@osdl.org> wrote:
> 
> > > So, say interrupts were enabled when entering apm_bios_call*(); you now
> > > save that in flags, disable interrupts, and enable them again.
> > > Upon reaching local_irq_restore(), we'll hit the else branch with irq's
> > > enabled and call trace_hardirqs_on(), which goes EEEK!
> > 
> > I'd assumed lockdep was less stupid than that ;) This?  Seems a bit 
> > overdone..
> 
> the problem is not lockdep but that the BIOS enables IRQs behind the 
> back of the kernel. Lockdep needs to be taught about that - if this 
> happens unconditionally then i'd suggest to insert an unconditional 
> trace_hardirqs_on() call to after the local_irq_save() that we do prior 
> calling the BIOS. (that will be a NOP if lockdep is not enabled)

Well, its not quite like that, the irq mess in apm does an explicit
unbalanced irq action, and lockdep rightly triggers on that.
And adding to that comes the fact that we do indeed call a BIOS routine
which can do god knows what.

So we want to save irq state and force it into a known state; normally
it will only be disable - however in this case (when
apm_info.allow_ints) we force enable it. All end scope routines expect
irqs disabled.

logically it looks something like this

local_irq_save(flags)
local_irq_enable()
...
local_irq_disable() <--- missing
local_irq_restore(flags)

except that the first two statements are blended together to avoid the
unneeded disable.

The logic is sound because local_irq_restore will just set whatever was
saved, except lockdep gets confused by the unbalanced operations - a
good thing IMHO.