linux-kernel - Re: 2.6.19-rc3-git7: scsi_device_unbusy: inconsistent lock state

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1162230993.2948.60.camel@laptopd505.fenrus.org>
Date:	Mon, 30 Oct 2006 18:56:33 +0100
From:	Arjan van de Ven <arjan@...radead.org>
To:	Jens Axboe <jens.axboe@...cle.com>
Cc:	Mark Lord <liml@....ca>,
	IDE/ATA development list <linux-ide@...r.kernel.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>, mingo@...e.hu
Subject: Re: 2.6.19-rc3-git7: scsi_device_unbusy: inconsistent lock state


> > 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@...ux.intel.com>

-- 
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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/