[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] earlier remove the backend of tapdisk device in xenstore to release the resource allocated in backend driver lies in dom0'kernel



>>> "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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.