[Xen-devel] çåï Re: [PATCH] fix race condition between libvirtd event handling and libxl fd deregister

["Bamvor Jian Zhang" <bjzhang@xxxxxxxx>]

The first menthol is already provided by libvirt though libvirt mutex which is 
a per-event lock.
And because this lock release before libxl callback entering, libxl got the 
chance to remove 
handles.

>>> Ian Campbell <Ian.Campbell@xxxxxxxxxx> 12å11æ28æ äå 19:25 >>>
On Tue, 2012-11-27 at 19:08 +0000, Ian Jackson wrote:
> what change to the libxl API syntax or semantics would fix the problem ?

Mostly just thinking out loud here...

Can we provide, or (more likely) require the application to provide, a
lock (perhaps per-event or, again more likely, per-event-loop) which
must be held while processing callbacks and also while events are being
registered/unregistered with the application's event handling subsystem?
With such a lock in place the application would be able to guarantee
that having returned from the deregister hook any further events would
be seen as spurious events by its own event processing loop.

The other scheme which springs to mind is to do reference counting, with
the application holding a reference whenever the event is present in its
event loop (such that there is any chance of the event being generated)
and libxl holding a reference while it considers the event to be active
(which roughly corresponds to the existing register/unregister hook
calls, I think). libxl would drop its reference as part of calling the
deregister hook while the application would hold its reference until it
was certain the event would no longer be generated e.g. in a pass at the
top of its event handling loop where it includes or excludes the
relevant fd from its select()/poll().

Last half brained idea would be to split the deregistration into two.
libxl calls up to the app saying "please deregister" and the app calls
back to libxl to say "I am no longer watching for this event and
guarantee that I won't deliver it any more". (Presumably this would be
implemented by the application via some combination of the above). This
could be done in a somewhat compatible way by allowing the deregister
hook to return "PENDING".

Ian.





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