This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [PATCH 2/2] reap the blktapctl thread and notify the tap

To: "Ian Jackson" <Ian.Jackson@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 2/2] reap the blktapctl thread and notify the tapdisk backend driver to release resource like memory..
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Mon, 10 May 2010 08:06:54 +0100
Cc: Jim Fehlig <JFEHLIG@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, James Song <JSong@xxxxxxxxxx>
Delivery-date: Mon, 10 May 2010 00:07:49 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <19428.20126.27164.576006@xxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4BE170FE0200002000085C39@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <19426.59365.615882.575878@xxxxxxxxxxxxxxxxxxxxxxxx> <4BE3DB5A0200007800001BB7@xxxxxxxxxxxxxxxxxx> <19428.20126.27164.576006@xxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> 07.05.10 19:32 >>>
>In fact however there is allegedly some bug somewhere which this patch
>is supposed to deal with, but I can't really see the connection.

The bug was with the blktap kernel driver not being able to clean up
after an unclean exit of qemu. We had reports of this only for 3.4
and 4.0 (and I wonder how no-one else noticed this, when the bug
was introduced about a year ago, even before blktap2 got added),
yet the problematic blktap code also existed in those systems that
we ship with 3.2.3 and 3.3.1, hence either no-one ever noticed the
problem on those platforms, or there must be a behavioral
difference of qemu (i.e. cleaning up after itself in earlier versions).

I fully agree that the kernel should (or really has to) properly clean
up after any uncleanly exiting application, yet ...

>I think in general we should be aiming for crash-only software.
>  http://dslab.epfl.ch/pubs/crashonly/crashonly.pdf 
>It's much much more reliable, as well as meaning we need to write less
>code (and thus fewer bugs).

... I can see a philosophical point in this discussion (but I don't
agree that this is the only sensible position).


Xen-devel mailing list