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

Stefan Berger stefanb at linux.vnet.ibm.com
Tue Feb 15 14:43:31 UTC 2011


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




More information about the libvir-list mailing list