I am working on making rds-tcp to be netns-aware, and in addition to a few bug fixes that I'm lining up, there's a basic issue with the way rds-tcp sets up the listen socket that is causing problems
The RDS tcp listen endpoint is created as part of module init. (rds_tcp_init -> rds_tcp_listen_init()). So this means that if I create a "blue" netns, and 'modprobe rds_tcp' within that netns, I get a kernel socket attached to the blue netns (which is good), but then I cannot use the same technique to set up a socket for a different netns ('modprobe rds_tcp' in that netns will return silently, as it should). And there's another downside to this design: the socket wont get released till the module is unloaed, so it ends up holding the reference on the net. So perhaps it was not a good idea to set up the listen socket as part of module init, but I'm trying to figure out a clean design for setting up the listen socket. Some uspace daemon that listens for changes to namespaces and reacts appropriately? A separate sysctl that sets up the listen endpoint in each namespace? Are there other subsystems that have to handle a similar case? I suspect that RDS-TCP is somewhat unusual here- I think most other similar encaps protocols like vxlan etc are associated with a network driver, so the listen endpoint is created as part of the ->ndo_open Suggestions for other modules that have to deal with a similar situation that I can refer to are invited.. --Sowmini -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html