Re: [PATCH 1/1] namespaces: introduce sys_hijack (v11)

[Bastian Blank <bastian-yyjItF7Rl6lg9hUCZPvPmw@public.gmane.org>]

On Fri, Aug 01, 2008 at 09:11:53AM -0500, Serge E. Hallyn wrote:
> Quoting Bastian Blank (bastian-yyjItF7Rl6lg9hUCZPvPmw@public.gmane.org):
> > On Thu, Jul 31, 2008 at 01:32:13PM -0500, Serge E. Hallyn wrote:
> > > The effect is a sort of namespace enter.  The following program
> > > uses sys_hijack to 'enter' all namespaces of the specified
> > > cgroup.
> > 
> > I currently fail to see what the differences to a normal cgroup attach
> > is.
> 
> A normal cgroup attach doesn't switch a task's root and nsproxies.

> Current functionality doesn't suffice because namespaces and
> fs_struct are not switched with cgroup attach.  Cgroup attach is
> just about tracking tasks, and keeping stats and enforcing limits or
> guarantees on the groups.

If you apply a nsproxy to a cgroup, it is part of its limits.

> The problem with implementing this feature using the attach
> semantics is that it would move an existing task into the new
> cgroup.  That would get much more complicated, especially when
> you consider pid namespaces, where we explicitly refuse to
> unshare for the same reason.

Okay, this is a reason. But I think it should disallow attach after the
nsproxy is set, otherwise you can use attach and hijack for the same
cgroup and produce different behaviour. The description of the
can_attach method does not mention such a test, but it seems to do one.

Why is it not enough to use the pid of the ns creator? The ns cgroups
are created including the pid in the name. And it would avoid using that
weird interface with fd of a cgroups file.

> That is why, with hijack, we clone a new task which is started
> afresh in the new namespaces.

Why did you name it "hijack"? If I had not read the mail, I'd no idea
what this is about. It does not take away the information from something
else, it overrides the information (nsprox, fs) on the new task.

But I think I have a different problem. Currently, namespaces are
destructed if the last process using them exits. You change that, they
will survive until the cgroup dies. Or is that cgroup destructed when
there are no longer processes using the nsproxy? As the commit message
speaks about "pid wraparound" as problem, I doubt that.

Bastian

-- 
To live is always desirable.
		-- Eleen the Capellan, "Friday's Child", stardate 3498.9