Eric W. Biederman wrote:
Dave Hansen <[email protected]> writes:
On Tue, 2006-01-17 at 20:55 -0800, Greg KH wrote:
On Tue, Jan 17, 2006 at 09:25:14AM -0800, Dave Hansen wrote:
Arjan had a very good point last time we posted these: we should
consider getting rid of as many places in the kernel where pids are used
to uniquely identify tasks, and just stick with task_struct pointers.
That's a very good idea, why didn't you do that?
Because we were being stupid and shoudn't have posted this massive set
of patches to LKML again before addressing the comments we got last
time, or doing _anything_ new with them.
Actually a little progress has been made. I think the patch set
continues to the point of usability this time or at least is close.
Although it feels like there are still some gaps when I read through
it.
Eric
Let me just summarize the discussion that has taken place so far
and the consequences I/we seem to be drawing out of it.
We discussed the various approaches that are floating around now, enough
has been said about each, so I leave it at that ...
(a) GLIBC intercept LD_PRELOAD
(b) Binary Rewrite of glibc
(c) syscall table intercept (see ZAP)
(d) vpid approach (see "IBM" patches posted)
(e) <pid,container> approach (see below, suggested by Alan?.. )
There are several issues that came up in the email exchange ( Arjen, Alan Cox, .. ).
[ Please feel free to tell me if I/we captured or misinterpregin these wrong ]
1st:
====
Issue: we don't need all the task_pid() etc functions just stick to what
it was task->pid !
Consens: It seems consensus is forming on that ..
Actions: remove the patches 1-12/34 and adopt the rest straight forward
2nd:
====
Issue: we don't need pid virtualization, instead simply use <container,pid> pair.
This requires a bit more thought. Essentially that's what I was doing, but I mangled
them into the same pid and using masking to add/remove the container for internal use.
As pointed out by Alan(?), we can indeed reused the same pid internally many times
as long as we can distinguish during the pid-to-task_struct lookup. This is easily
done because, the caller provides the context hence the container for the lookup.
Actions: The vpid_to_pid will disappear and the check for whether we are in the same
container needs to be pushed down into the task lookup. question remains to figure out
whether the context of the task lookup (will always remain the caller ?).
Doing so has an implication, namely that we are moving over to "system containers".
The current implementation requires the vpid/pid only for the boundary condition at the
top of the container (to rewrite pid=1) and its parent and the fact that we wanted
a global look through container=0.
If said boundary would be eliminated and we simply make a container a child of the
initproc (pid=1), this would be unnecessary.
all together this would provide private namespaces (as just suggested by Eric).
The feeling would be that large parts of patch could be reduce by this.
What we need is a new system calls (similar to vserver) or maybe we can continue
the /proc approach for now...
sys_exec_container(const *char container_name, pid_t pid, unsigned int flags, const *char argv, const *char envp);
exec_container creates a new container (if indicated in flags) and a new task in it that reports to parent initproc.
if a non-zero pid is specified we use that pid, otherwise the system will allocate it. Finally
it create new session id ; chroot and exec's the specified program.
What we loose with this is the session and the tty, which Cedric described as application
container...
The sys_exec_container(...) seems to be similar to what Eric just called clone_namespace()
-- Hubertus
______________________________________________________
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
