From: ebiederm@xmission.com (Eric W. Biederman)
To: Alun Evans <alun@badgerous.net>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 05/27] containers: Open a socket inside a container
Date: Fri, 27 Sep 2019 09:46:39 -0500 [thread overview]
Message-ID: <871rw1yey8.fsf@x220.int.ebiederm.org> (raw)
In-Reply-To: <m2o8z7t2w5.fsf@badgerous.net> (Alun Evans's message of "Thu, 26 Sep 2019 09:53:46 -0700")
Alun Evans <alun@badgerous.net> writes:
> Hi Eric,
>
>
> On Tue, 19 Feb 2019, Eric W. Biederman <ebiederm@xmission.com> wrote:
>>
>> David Howells <dhowells@redhat.com> writes:
>>
>> > Provide a system call to open a socket inside of a container, using that
>> > container's network namespace. This allows netlink to be used to manage
>> > the container.
>> >
>> > fd = container_socket(int container_fd,
>> > int domain, int type, int protocol);
>> >
>>
>> Nacked-by: "Eric W. Biederman" <ebiederm@xmission.com>
>>
>> Use a namespace file descriptor if you need this. So far we have not
>> added this system call as it is just a performance optimization. And it
>> has been too niche to matter.
>>
>> If this that has changed we can add this separately from everything else
>> you are doing here.
>
> I think I've found the niche.
>
>
> I'm trying to use network namespaces from Go.
Yes. Go sucks for this.
> Since setns is thread
> specific, I'm forced to use this pattern:
>
> runtime.LockOSThread()
> defer runtime.UnlockOSThread()
> …
> err = netns.Set(newns)
>
>
> This is only safe recently:
> https://github.com/vishvananda/netns/issues/17#issuecomment-367325770
>
> - but is still less than ideal performance wise, as it locks out other
> socket operations.
>
> The socketat() / socketns() would be ideal:
>
> https://lwn.net/Articles/406684/
> https://lwn.net/Articles/407495/
> https://lkml.org/lkml/2011/10/3/220
>
>
> One thing that is interesting, the LockOSThread works pretty well for
> receiving, since I can wrap it around the socket()/bind()/listen() at
> startup. Then accept() can run outside of the lock.
>
> It's creating new outbound tcp connections via socket()/connect() pairs
> that is the issue.
As I understand it you should be able to write socketat in go something like:
runtime.LockOSThread()
err = netns.Set(newns);
fd = socket(...);
err = netns.Set(defaultns);
runtime.UnlockOSThread()
I have no real objections to a kernel system call doing that. It has
just never risen to the level where it was necessary to optimize
userspace yet.
Eric
next parent reply other threads:[~2019-09-27 14:47 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <m2o8z7t2w5.fsf@badgerous.net>
2019-09-27 14:46 ` Eric W. Biederman [this message]
2019-09-28 22:29 ` [RFC PATCH 05/27] containers: Open a socket inside a container Alun Evans
2019-09-30 10:02 ` Eric W. Biederman
2019-02-15 16:07 [RFC PATCH 00/27] Containers and using authenticated filesystems David Howells
2019-02-15 16:07 ` [RFC PATCH 05/27] containers: Open a socket inside a container David Howells
2019-02-19 16:41 ` Eric W. Biederman
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=871rw1yey8.fsf@x220.int.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=alun@badgerous.net \
--cc=linux-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox