diff options
author | Ian Jackson <ian.jackson@eu.citrix.com> | 2013-01-24 12:47:52 +0000 |
---|---|---|
committer | Ian Jackson <ian.jackson@eu.citrix.com> | 2013-01-24 12:47:52 +0000 |
commit | bc7e8a2a813e0acfddd62fa5b6c4571ada8d1cd1 (patch) | |
tree | 6e0f050e1e7922805cdba23a0e87494972b8efec /stubdom | |
parent | 9f0443bafbab97831e5c99553bf9f0805537f3fc (diff) | |
download | xen-bc7e8a2a813e0acfddd62fa5b6c4571ada8d1cd1.tar.gz xen-bc7e8a2a813e0acfddd62fa5b6c4571ada8d1cd1.tar.bz2 xen-bc7e8a2a813e0acfddd62fa5b6c4571ada8d1cd1.zip |
libxl: fix stale fd event callback race
Because there is not necessarily any lock held at the point the
application (eg, libvirt) calls libxl_osevent_occurred_timeout and
..._fd, in a multithreaded program those calls may be arbitrarily
delayed in relation to other activities within the program.
libxl therefore needs to be prepared to receive very old event
callbacks. Arrange for this to be the case for fd callbacks.
This requires a new layer of indirection through a "hook nexus" struct
which can outlive the libxl__ev_foo. Allocation and deallocation of
these nexi is mostly handled in the OSEVENT macros which wrap up
the application's callbacks.
Document the problem and the solution in a comment in libxl_event.c
just before the definition of struct libxl__osevent_hook_nexus.
There is still a race relating to libxl__osevent_occurred_timeout;
this will be addressed in the following patch.
Reported-by: Bamvor Jian Zhang <bjzhang@suse.com>
Cc: Bamvor Jian Zhang <bjzhang@suse.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Tested-by: Jim Fehlig <jfehlig@suse.com>
Acked-by: Jim Fehlig <jfehlig@suse.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
Diffstat (limited to 'stubdom')
0 files changed, 0 insertions, 0 deletions