lockdep badness

[Benjamin Herrenschmidt]

On Thu, 2008-07-24 at 14:38 -0500, Nathan Lynch wrote:
> Nathan Lynch wrote:
> > 
> > A couple of stack traces below, the first is from benh's tree, the
> > second is from 2.6.26.  The lockdep self-tests all pass at boot.
> 
> Sorry, should have pointed out the code that is warning more
> specifically.
> 
> 
> > RTAS daemon started
> > RTAS: event: 295, Type: Dump Notification Event, Severity: 2
> > ------------[ cut here ]------------
> > Badness at kernel/lockdep.c:2719
> 
> check_flags():
> 
>         if (irqs_disabled_flags(flags)) {
>                 if (DEBUG_LOCKS_WARN_ON(current->hardirqs_enabled)) {
>                         printk("possible reason: unannotated
>                 irqs-off.\n");
>                 }
>         } else {
> >>>             if (DEBUG_LOCKS_WARN_ON(!current->hardirqs_enabled)) {
>                         printk("possible reason: unannotated
>                 irqs-on.\n");
>                 }
>         }

Yes, it looks like at some point the IRQ state gets out of sync, and I
haven't found out where yet. Having a repro case would help, what is the
setup of your machine ? I seems to be related to having an RTAS event at
boot.


> > ipr: IBM Power RAID SCSI Device Driver version: 2.4.1 (April 24, 2007)
> > ipr 0000:00:01.0: Found IOA with IRQ: 289
> > ipr 0000:00:01.0: Starting IOA initialization sequence.
> > ipr 0000:00:01.0: Adapter firmware version: 02200023
> > ipr 0000:00:01.0: IOA initialized.
> > ------------[ cut here ]------------
> > Badness at kernel/lockdep.c:2037
> 
> trace_hardirqs_on():
> 
>         if (DEBUG_LOCKS_WARN_ON(!irqs_disabled()))
>                 return;
> >>>     if (DEBUG_LOCKS_WARN_ON(current->hardirq_context))
>                 return;

As I said before, I'm not 100% sure what that is, it smells like
something legal that Ingo made not so anymore but I need to double
check.

Cheers,
Ben.