> > 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 <[email protected]>
--
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-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
