Re: [PATCH] macvtap: Work-around failing nl_connect calls (weird problem)

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

 



On 02/14/2011 11:43 PM, Stefan Berger wrote:
One definte problem in libnl is that the 'port allocation' (generate_local_port()) is not thread-safe, even though I think it's the library's responsibility to lock, not libvirt introducing a lock that we need to grab before calling into netcf and grabbing in macvtap. Unless libnl fixes this, I believe there will be no other way than retrying. One will eventually bind and exclude a concurrent thread from binding.


It's late but this doesn't look right even now in libnl (libnl-debuginfo-1.1-12.fc14.x86_64):

port allocation (socket.c ; line 134):
used_ports_map[i] |= (1UL << n);

- that's going to set a bit

port deallocation (socket.c; line 156) :
used_ports_map[nr / 32] &= ~((nr % 32) + 1);


- that's going to produce garbage; no wonder things don't work


used_ports_map[nr / 32] &= ~(1 << (nr % 32));

or

used_ports_map[nr / 32] &= ~(1 << (nr & 0x1f));

- would probably be much better


I am withdrawing this patch. I filed bugzilla(s) against libnl, which needs patching. I hope it comes back quickly in form of an updated rpm.

   Stefan

--
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]