From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=54114 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1OEewT-0004jC-OF
	for qemu-devel@nongnu.org; Wed, 19 May 2010 04:47:58 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <kwolf@redhat.com>) id 1OEe1z-0004UD-3K
	for qemu-devel@nongnu.org; Wed, 19 May 2010 03:49:39 -0400
Received: from mx1.redhat.com ([209.132.183.28]:9464)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <kwolf@redhat.com>) id 1OEe1m-0004Sj-W5
	for qemu-devel@nongnu.org; Wed, 19 May 2010 03:49:21 -0400
Message-ID: <4BF397DF.2030108@redhat.com>
Date: Wed, 19 May 2010 09:48:47 +0200
From: Kevin Wolf <kwolf@redhat.com>
MIME-Version: 1.0
References: <4BDF3F94.1080608@dlh.net> <4BDFDC44.9030808@redhat.com>
	<4BE00750.6040804@dlh.net> <4BE01120.30608@redhat.com>
	<4BE02440.6010802@dlh.net> <4BE028BF.1000603@redhat.com>
	<4BEAB4B0.70803@dlh.net> <4BED1740.1080604@redhat.com>
	<4BF275B1.8030106@dlh.net> <4BF2949C.8010108@redhat.com>
	<20100519072902.GA711@lst.de>
In-Reply-To: <20100519072902.GA711@lst.de>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] Re: qemu-kvm hangs if multipath device is queing
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Christoph Hellwig <hch@lst.de>
Cc: Peter Lieven <pl@dlh.net>, qemu-devel@nongnu.org, kvm@vger.kernel.org

Am 19.05.2010 09:29, schrieb Christoph Hellwig:
> On Tue, May 18, 2010 at 03:22:36PM +0200, Kevin Wolf wrote:
>> I think it's stuck here in an endless loop:
>>
>>     while (laiocb->ret == -EINPROGRESS)
>>         qemu_laio_completion_cb(laiocb->ctx);
>>
>> Can you verify this by single-stepping one or two loop iterations? ret
>> and errno after the read call could be interesting, too.
> 
> Maybe the compiler is just too smart.  Without some form of barrier
> it could just optimize the loop away as laiocb->ret couldn't change
> in a normal single-threaded environment.

It probably could in theory, but in practice we're in a read() inside
qemu_laio_completion, so it didn't do it here.

Kevin