WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] earlier remove the backend of tapdisk device in xenstore

To: "James Song" <JSong@xxxxxxxxxx>
Subject: Re: [Xen-devel] earlier remove the backend of tapdisk device in xenstore to release the resource allocated in backend driver lies in dom0'kernel
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Fri, 23 Apr 2010 09:13:29 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 23 Apr 2010 01:14:17 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <28337027.post@xxxxxxxxxxxxxxx>
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: <28325456.post@xxxxxxxxxxxxxxx> <4BD04B87020000780003B5F4@xxxxxxxxxxxxxxxxxx> <28337027.post@xxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> "James (song wei)" <jsong@xxxxxxxxxx> 23.04.10 05:24 >>>
>Jan Beulich wrote:
>> More generally any solution should be generic, or it should be
>> explained properly why the device class needs treatment
>> different from any of the other ones (and, for this specific
>> case, why moving the device destruction a little ahead will
>> now *guarantee* that the cleanup can happen as expected).
> 
> 
> Moving the device destruction a little ahead of  killing qemu-dm would
> triger blktapctl thread send CTRMSG_CLOSE to "qemu-dm" before it exit. 
> And then, qemu-dm would notify backend driver to release resouce by
> calling release() of driver through closing the opened device file of
> "/dev/xen/blktapN" 

Even though Keir already applied your patch, I continue to disagree:
The only function you modified is XendDomainInfo._releaseDevices(),
which itself doesn't kill qemu-dm afaict (I didn't actually spot where
it gets killed). Hence the only effect you achieve is that the window
in time for the CTRLMSG_CLOSE to arrive gets enlarged (the insertion
of time.sleep(0.1) is also a sign of just using heuristics instead of
proper sequencing of events). You still can't guarantee that the
message will arrive in time (i.e. if qemu-dm doesn't get scheduled
soon enough), and hence you just decreased the likelihood of the
original issue.

Imo, there's no way around doing proper cleanup from qemu-dm's
signal handler, or there needs to be better handshaking between
xend and qemu-dm.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel