aboutsummaryrefslogtreecommitdiffstats
path: root/stubdom
diff options
context:
space:
mode:
authorIan Jackson <ian.jackson@eu.citrix.com>2013-01-24 12:47:52 +0000
committerIan Jackson <ian.jackson@eu.citrix.com>2013-01-24 12:47:52 +0000
commitbc7e8a2a813e0acfddd62fa5b6c4571ada8d1cd1 (patch)
tree6e0f050e1e7922805cdba23a0e87494972b8efec /stubdom
parent9f0443bafbab97831e5c99553bf9f0805537f3fc (diff)
downloadxen-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