> > what I meant is that cfq_set_request() calls a few inlines that also > > take locks so it might be one of those instead > > I looked over them, and cfq_cic_link() should use _irqsave() instead of > _irq() if called without __GFP_WAIT set. That doesn't happen in the > normal io path though, so I'm not sure that is it. > > So if the bug is using spin_lock_irq() with interrupts already disabled, > iirc that would trigger a different warning... it's not spin_lock_irq() that'll warn, but the unlock... :) > Naturally, that is a bug fair and simple, nothing to do with lockdep. > > > diff --git a/block/cfq-iosched.c b/block/cfq-iosched.c > index 4bae64e..da9bddf 100644 > --- a/block/cfq-iosched.c > +++ b/block/cfq-iosched.c > @@ -1355,6 +1355,7 @@ cfq_cic_link(struct cfq_data *cfqd, stru > structirely reason rb_node **p; > struct rb_node *parent; > struct cfq_io_context *__cic; > + unsigned long flags; > void *k; > > cic->ioc = ioc; > @@ -1384,9 +1385,9 @@ restart: > rb_link_node(&cic->rb_node, parent, p); > rb_insert_color(&cic->rb_node, &ioc->cic_root); > > - spin_lock_irq(cfqd->queue->queue_lock); > + spin_lock_irqsave(cfqd->queue->queue_lock, flags); > list_add(&cic->queue_list, &cfqd->cic_list); > - spin_unlock_irq(cfqd->queue->queue_lock); > + spin_unlock_irqrestore(cfqd->queue->queue_lock, flags); > } this looks entirely reasonable and correct Acked-By: Arjan van de Ven <arjan@xxxxxxxxxxxxxxx> -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
