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
