On 05/01/2012 03:16 PM, Eric Blake wrote: > On 05/01/2012 01:05 PM, Laine Stump wrote: >> The two following patches fix the same problem (described in >> https://bugzilla.redhat.com/show_bug.cgi?id=816465) in two alternate >> ways - one by retrying the failing operation after a delay, the other by >> using knowledge of how libnl works internally to artificially "reserve" >> a particular address so libnl doesn't attempt to bind to it. >> >> You might think that libnl is the right place to fix this bug. >> Unfortunately, that isn't possible, because it would involve changing >> libnl's API - currently libnl decides what address to use for future >> binds of a netlink socket at the time nl_handle_alloc() is called, but >> doesn't actually attempt to bind it. Later, during nl_connect(), it >> calls bind() with the address it had earlier decided. It would be nice >> if we could just retry the bind with a different address when the first >> attempt failed, but libnl allows client applications to retrieve the >> bind address *before nl_connect() is called*, so an application may have >> already gotten the address prior to calling nl_connect(), and changing >> it would render the applications information incorrect. > Does libnl-3 have the same issue? It would be interesting if Serge > Hallyn's patches to support libnl-3 ended up allowing us to move to a > version of the library that doesn't have the same fundamental flaw. > Have we complained about this flaw to the libnl upstream folks? Yes, libnl-3 has the same flaw in the API/code, but no I haven't contacted them about it yet - I've been too busy gathering information. That's on my list of things to do, though (actually I'm thinking it would be good to have the libnl maintainer take a look at Serge's patches - he had earlier agreed to help out with making libvirt libnl-3-compliant when we got around to it). -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list