Netlink sockets and concurrency
mdlayher at gmail.com
Thu Feb 23 07:38:21 PST 2017
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
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