All of lore.kernel.org
 help / color / mirror / Atom feed
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.