Re: [PATCH alternative 2] util: fix libvirtd startup failure due to netlink error

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]