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

Re: [Xen-devel] [PATCH] libxl: do not fail device removal if backend domain is gone



On Fri, Feb 09, 2018 at 12:10:39PM +0000, Roger Pau Monné wrote:
> On Fri, Feb 09, 2018 at 12:41:58PM +0100, Marek Marczykowski-Górecki wrote:
> > On Fri, Feb 09, 2018 at 11:27:04AM +0000, Roger Pau Monné wrote:
> > > I'm also wondering, if you jump to 'out' here, you avoid the call to
> > > libxl__xs_transaction_commit and instead end up calling
> > > libxl__xs_transaction_abort, which means the above call to
> > > libxl__xs_path_cleanup will not be committed to xenstore, is this
> > > really desired?
> > >
> > > It seems to me libxl might leak xenstore frontend entries in that
> > > case.
> > 
> > That call is only if aodev->force. In other cases cleanup is done in
> > device_hotplug_done()->libxl__device_destroy(), which have its own 
> > transaction.
> 
> Hm, right, but this would still be incorrect in the force case then?
> Or is this simply not needed for the 'force' case?

In that case, the first libxl__xs_path_cleanup will indeed be aborted.
But then it will be cleaned up the same way as in !force case.
Anyway, this is about the case when backend is already gone, so 'force'
doesn't really change anything - it was forcefully removed already, by
shutting down the backend domain (or removing backend using something
else)...

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

Attachment: signature.asc
Description: PGP signature

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

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