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

Re: [Xen-devel] [PATCH 2/2] libxl: fix stale timeout event callback race



Jim Fehlig writes ("Re: [Xen-devel] [PATCH 2/2] libxl: fix stale timeout event 
callback race"):
> Ian Jackson wrote:
> > Well your patch is only correct when used with the new libxl, with my
> > patches.
> 
> Hmm, it is not clear to me how to make the libxl driver work correctly
> with libxl pre and post your patches :-/.

This should be straightforward I think, except for the deregistration
race bug which is unavoidable with the old libxl.  Simply correctly
implementing both the deregistration callback and the modification
callback ought to do it.

> >> @@ -184,6 +184,8 @@ static void libxlTimerCallback(int timer
> >> ATTRIBUTE_UNUSED, void *timer_v)
> >>  {
> >>      struct libxlOSEventHookTimerInfo *timer_info = timer_v;
> >>  
> >> +    virEventRemoveTimeout(timer_info->id);
> >> +    timer_info->id = -1;
> >>     
> >
> > I don't understand why you need this.  Doesn't libvirt remove timers
> > when they fire ?  If it doesn't, do they otherwise not keep reoccurring ?
> 
> No, timers are not removed when they fire.  And they are continuous, so
> will keep firing at each timeout.  They can be disabled by setting the
> timeout to -1, and can be set to fire on each iteration of the event
> loop by setting the timeout to 0.  But they must be explicitly removed
> with virEventRemoveTimeout when no longer needed.

Right.  Well then yes you need to call virEventRemoveTimeout here.
But that applies to both old and new libxl.

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®.