On 05/01/2012 01:11 PM, Laine Stump wrote:
This is an alternate method of solving the problem detailed in:
https://bugzilla.redhat.com/show_bug.cgi?id=816465
Testing has shown that if we "reserve" the bind address of "pid of
libvirtd" so that libnl never tries to bind it, our bind of "pid of
libnl + (1 << 22)" (which is what libnl ends up using for the 2nd
s/pid of libnl/pid of libvirtd/
socket it binds) will *always* succeed the first time. The way to
make
this reservation is to allocate a handle from libnl (it internally
assigns the address it will use at handle alloc time), then just never
use that handle - it is a place holder for whatever other code in the
process is using netlink sockets directly (i.e. not through libnl).
Kind of gross to be relying on undocumented internals, but we already
know that libnl will be changing API when we add libnl-3 support (and
possibly again, once you report this design flaw upstream); and we also
have the argument that libnl is open source code so we are doing this
based on actual code inspection (and not random guesses) - if libnl were
a proprietary library, we'd be stuck.
The advantage of this patch over the other is that it doesn't rely on
timing at all.
And that's why I like this more than alternative 1.
The disadvantage (?maybe? maybe not, I'm not sure - someone more
knowledgeable about the libvirtd<->lldpad communication please inform)
is that the bind address used by the netlink socket that communicates
with lldpad will be "pid of libvirtd + (1 << 22)", not "pid of
libvirtd".
I don't know of any downside, but I also am not knowledgeable about
lldpad, so I could be entirely missing something. If that proves to be
a problem in practice, speak up now, and we can go with option 1; but if
no one speaks up, I like option 2 better.
ACK to the actual code for this workaround, although...
+ srv->netlinknh = NULL;
+ /* Allocate a dummy nl_handle to reserve the address "pid of
+ * libvirtd" for whatever library is using it.
Adding a URL to this thread (and/or a thread on the libnl list reporting
the problem) might be nice for future reference.
--
Eric Blake eblake(a)redhat.com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org