On 05/03/2012 09:10 AM, Laine Stump wrote:
This solves the problem detailed in:
https://bugzilla.redhat.com/show_bug.cgi?id=816465
and further detailed in
https://www.redhat.com/archives/libvir-list/2012-May/msg00202.htm
A short explanation is included in the comments of the patch itself.
Even with ACK, I will wait to push this until I have verification that
it does not break lldpad<-->libvirtd communication (if it does, I may
need to use the nl_handle allocated during virNetlinkStartup() for
virNetlinkEventServiceStart()).
This last paragraph needs modification to instead describe actual
testing results before you push.
---
daemon/libvirtd.c | 6 +++++
src/libvirt_private.syms | 2 ++
src/util/virnetlink.c | 67 +++++++++++++++++++++++++++++++++++++++++++++-
src/util/virnetlink.h | 5 +++-
4 files changed, 78 insertions(+), 2 deletions(-)
ACK to this patch with one nit, once the testing is complete (assuming
positive test results); worth including in 0.9.12, so hopefully we get
results soon.
+ * The short version is that, without this placeholder allocation
of
+ * an nl_handle that is never used, it is possible for nl_connect() in
+ * one thread to collide with a direct bind() of a netlink socket in
+ * another thread, leading to failure of the operation (which could
+ * lead to failure of libvirtd to start). Since getaddrinfo() (used by
+ * libvirtd in virSocketAddrParse, which is called quite frequently
+ * during startup) directly calls bind() on a netlink socket, this is
+ * actually a very common occurence (15-20% failure rate on some
s/occurence/occurrence/
--
Eric Blake eblake(a)redhat.com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org