From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1Gum32-0007rk-Pf
	for qemu-devel@nongnu.org; Thu, 14 Dec 2006 03:34:36 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1Gum30-0007r7-Jn
	for qemu-devel@nongnu.org; Thu, 14 Dec 2006 03:34:36 -0500
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Gum30-0007qs-Bx
	for qemu-devel@nongnu.org; Thu, 14 Dec 2006 03:34:34 -0500
Received: from [64.78.21.129] (helo=mis011-2.exch011.intermedia.net)
	by monty-python.gnu.org with esmtp (Exim 4.52) id 1Gum30-0001q5-B2
	for qemu-devel@nongnu.org; Thu, 14 Dec 2006 03:34:34 -0500
Message-ID: <45810C90.2070707@qumranet.com>
Date: Thu, 14 Dec 2006 10:34:24 +0200
From: Avi Kivity <avi@qumranet.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] Re: NBD server for QEMU images
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>
	<elpj4s$dlj$1@sea.gmane.org>
In-Reply-To: <elpj4s$dlj$1@sea.gmane.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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

Salvador Fandino wrote:
> 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.
>
>   

If you use sysrq-t and a serial console, you will find exactly how it's 
waiting for memory.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.