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

Re: [Xen-devel] [PATCH 01/27] tools/libxl: Fix libxl__ev_child_inuse() check for not-yet-initialised children



On Tue, 2015-06-16 at 14:36 +0100, Andrew Cooper wrote:
> On 16/06/15 14:21, Ian Campbell wrote:
> > On Mon, 2015-06-15 at 14:44 +0100, Andrew Cooper wrote:
> >> Shortly, libxl will be juggling multiple parallel operations, and will
> >> possibly have to take error decisions before some tasks have been set up.
> > It would be preferable, I think, to arrange to call libxl__ev_child_init
> > on all such libxl__ev_child structs either up front or certainly before
> > there is any possibility of needing to unwind them.
> >
> > Such an init would at worst correspond to exactly the place where the
> > zeroed structure you refer to is zeroed.
> 
> It is possible that one bit fails before it can be calculated whether
> the second bit needs to start or not.

You can call libxl__ev_child_init without needing to know that, i.e. you
can do them all at the point where you allocate/initialise the
containing struct.

> At the moment, all bits in libxl in this area do initialisation
> immediately before use; most bits are even initialised in the function
> which starts their actions.  Some bits are initialised differently
> depending on the path taken to get to the initialisation site. 
> 
> It would be non-trivial to initialise everything appropriately at the
> very start.

You don't need to fully init, just call libxl__ev_child_init in order to
arrange for correct behaviour from libxl__ev_child_inuse and friends.
Actually turning it into a useful child can stay where it is if it is
tricky to arrange for those things to happen at the same time.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

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