From: Sowmini Varadhan <sowmini.varadhan@oracle.com>
To: netdev@vger.kernel.org
Cc: sowmini.varadhan@oracle.com
Subject: rfc: making rds-tcp netns aware
Date: Wed, 15 Jul 2015 13:04:53 +0200 [thread overview]
Message-ID: <20150715110453.GH6541@oracle.com> (raw)
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
reply other threads:[~2015-07-15 11:05 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150715110453.GH6541@oracle.com \
--to=sowmini.varadhan@oracle.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.