Netlink sockets and concurrency

Matt Layher mdlayher at gmail.com
Thu Feb 23 07:38:21 PST 2017


Hi all,

This question isn't directly related to libnl, but rather to netlink and 
netlink sockets themselves. I wasn't sure where else to ask, but I 
figured the folks on this list should have some good experience working 
with netlink.

I built a Go package (https://github.com/mdlayher/netlink) for working 
with netlink sockets, but am seeing some occasional strange behavior 
when attempting to use multiple sockets from the same application.

For whatever reason, netlink appears to occasionally send a reply 
message to the wrong socket, when being called concurrently.  I'm 
opening 16 genetlink sockets and giving each socket its own "thread" 
("goroutine" in Go).  I pick a sequence number at random for each 
socket, and then increment it each time a message is sent.

At this point, I send 10,000 messages from each socket with the flags 
"request + acknowledge", so netlink will echo back the message I sent to 
it.  Again, before each message is sent, I increment the internal 
sequence number of my socket wrapper.

For whatever reason, sometimes I receive a reply back from netlink with 
an unexpected sequence number.  The sequence number often looks like it 
was meant for another socket in the test, running in a different thread.

Is it safe to open multiple sockets to netlink (genetlink, specifically) 
in the same application and use them concurrently in this way? As far as 
I can tell, my code is free of race conditions in user-space (verified 
using Go's race detector).  I am not sharing a single socket between 
multiple threads.  I am simply sending and receiving on multiple sockets 
at the same time, in independent threads.

It doesn't appear that libnl has any special "global lock", other than 
the PID assignment map.  I am no C expert, but I'm curious if there is a 
workaround in libnl for making use of multiple sockets concurrently, to 
ensure that messages are delivered properly to the expected socket.

Thanks for your time.  I'd certainly appreciate any insight you all may 
have on this matter.

- Matt Layher



More information about the libnl mailing list