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@xxxxxxxxxx +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list