Does libnl support multihtreaded apps ?

Laine Stump laine at laine.org
Thu May 12 22:07:42 EDT 2011


On 05/12/2011 06:53 AM, Thomas Graf wrote:
> On Thu, May 12, 2011 at 12:44:58PM +0200, Romary Sonrier wrote:
>> So i checked into the var sk->s_local ( my process pid is 6808)
>> Thread that doesn't get any error : s_local = {nl_family = 16, nl_pad =
>> 0, nl_pid = 6808, nl_groups = 0},
>> Thread that does get an error : s_local = {nl_family = 16, nl_pad = 0,
>> nl_pid = 4201112, nl_groups = 0},
>>
>> I didn't took time to understand the function  generate_local_port(),
>> but it seems realy obscure to me.
>> As far a I understood generate_local_port(), the bit mapping seeme to be
>> correct:
>>   6808 :                   00000000001101010011000
>>   4201112:              10000000001101010011000
>>
>> So the question is for me : Does libnl support multihtreaded apps ?
>>
>> Does someone hase any idea ?
> In general libnl does support multithreaded apps. There are a few remaining
> problem areas, one of them is the above mentioned generate_local_port().
> There is a patch from NetworkManager which introduces proper locking. I
> just haven't gotten around merging it yet.

Here is the bug report that contains the patch you refer to (against 
libnl-1.1, so it may need some rebasing to work with 3.0):

    https://bugzilla.redhat.com/show_bug.cgi?id=677724

The problem was actually discovered in the context of using libnl from 
libvirt to setup macvtap interfaces (and it was a libvirt person who 
provided the patch, not that anyone's counting ;-) libvirt allows 
multiple threads, and uses libnl-1.1 both directly and via the netcf 
library. So far the only thread-related problems we've encountered have 
been with generate_local_port(), and with the global error string (which 
I believe has been altogether eliminated in newer versions of libnl). I 
would be very interested in hearing about other threading issues that 
may be carry-overs from libnl-1.1 (since at least Fedora and RHEL are 
still using that version).

Thinking about it, libvirt+netcf might be a good place to stretch 
libnl-3.0's thread muscles...




More information about the libnl mailing list