Hi All,

We have been using an application where we would require to monitor the netlink messages from all namespaces. Initial design is we had created one process per namespace and each process would open a socket in its own namespace and listen for netlink notifications. But this approach is not scalable to have one process per namespace.

I did come across setns system call which would change the namespace of the current process context and open a socket in that namespace and return back to the default namespace.In addition I used this command ip netns set NETNSNAME NETNSID which when used "NETLINK_LISTEN_ALL_NSID" in the socket option would receive netlink notification from multiple namespaces where the ID being passed in the ancillary date of the recvmsg system call. This seems to be working fine in most of the cases, but I do see issues when the interfaces are moved across namespaces in quick succession where the add IP netlink message did not have an ID associated which was set during the ip netns set call. Even though the message arrived because of the quick succession of moving the interfaces across namespaces I am thinking if there might be any race conditions. Also in few cases the ipv6 add route netlink message was missing even though the route was present in the table.

So what I would like to know is because of these quick succession of executing these commands in namespace, can there be any race conditions existing. Also I would like to know once ip netns set NETNSNAME NETNSID command is executed when can we reliably start executing the commands in the namespace.

Any pointers would be really helpful.

Thanks.
Param