From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1GuZUH-0006GQ-G9
	for qemu-devel@nongnu.org; Wed, 13 Dec 2006 14:09:53 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1GuZUA-0006CF-FC
	for qemu-devel@nongnu.org; Wed, 13 Dec 2006 14:09:49 -0500
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1GuZUA-0006C6-3T
	for qemu-devel@nongnu.org; Wed, 13 Dec 2006 14:09:46 -0500
Received: from [80.91.229.2] (helo=ciao.gmane.org)
	by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA:32)
	(Exim 4.52) id 1GuZU9-0003RK-Qk
	for qemu-devel@nongnu.org; Wed, 13 Dec 2006 14:09:46 -0500
Received: from list by ciao.gmane.org with local (Exim 4.43)
	id 1GuZTz-0006CG-18
	for qemu-devel@nongnu.org; Wed, 13 Dec 2006 20:09:35 +0100
Received: from 137.red-80-25-49.staticip.rima-tde.net ([80.25.49.137])
	by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for <qemu-devel@nongnu.org>; Wed, 13 Dec 2006 20:09:35 +0100
Received: from sfandino by 137.red-80-25-49.staticip.rima-tde.net with local
	(Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00
	for <qemu-devel@nongnu.org>; Wed, 13 Dec 2006 20:09:35 +0100
From: Salvador Fandino <sfandino@yahoo.com>
Date: Wed, 13 Dec 2006 20:14:58 +0100
Message-ID: <elpj4s$dlj$1@sea.gmane.org>
References: <20061212124803.47702.qmail@web52708.mail.yahoo.com>	<457EC621.6000701@codemonkey.ws>	<elmooq$rdl$1@sea.gmane.org>	<457F0D61.90008@codemonkey.ws>	<457FE5EE.4000704@qumranet.com>	<56d259a00612130519l2b324966o2f2cd6e5c69beb10@mail.gmail.com>
	<45800026.2010809@qumranet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
In-Reply-To: <45800026.2010809@qumranet.com>
Sender: news <news@sea.gmane.org>
Subject: [Qemu-devel] Re: NBD server for QEMU images
Reply-To: qemu-devel@nongnu.org
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.gnu.org/pipermail/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: qemu-devel@nongnu.org

Avi Kivity wrote:
> Martin Guy wrote:
>>> - write tons of data to nbd device, data ends up in pagecache
>>> - memory gets low, kswapd wakes up, calls nbd device to actually write
>>> the data
>>> - nbd issues a request, which ends up on the nbd server on the same
>>> machine
>>> - the nbd server allocates memory
>>> - memory allocation hangs waiting for kswapd
>>
>> In other words, it can deadlock only if you are swapping to an nbd
>> device that is served by nbd-server running on the same machine and
>> kernel. 
> 
> No.  It is possible if you issue non-O_SYNC writes.

I have run some tests and found that it's easy to cause a deadlock just
untaring a file over an nbd device being served from localhost (using
the standard nbd-server or my own, it doesn't matter).

Another interesting finding is that when the deadlock happens, qemu-nbds
is inside a read() call, waiting for new nbd requests to arrive over the
socket, and so, not trying to allocate memory or writing to disk.

BTW, I am using Debian unstable with kernel 2.6.18-1-686

Regards,

 - Salva