Skip to content

Was: pidns: Support unsharing the pid namespace.

Oleg Nesterov containers lkml 1 version In review

Get series with b4
b4 am [email protected]

Versions newest first

  1. v1 Latest1 patch 2 repliesIn review

Patches in v1 No applies recorded yet

#Subject and filesSizeRepliesApplied
1/1sys_unshare: remove the dead CLONE_THREAD/SIGHAND/VM codekernel/fork.c+25 -982 replies

Reviews trailers per patch

The patch has a Reviewed-by or Acked-by of their own; the series has one for all of them.

PatchRoland McGrathSerge Hallyn
SeriesA-b
1/1A-b A-b A-b

Trailers given in replies are filled; those carried in the patches from earlier versions are outlined with dashes.

Read the v1 thread

Cover letter [PATCH 0/1] Was: pidns: Support unsharing the pid namespace.
Quoted 31 lines · Oleg Nesterov
Quoted 3 lines · Daniel Lezcano

- Pass both nsproxy->pid_ns and task_active_pid_ns to copy_pid_ns As they can now be different.

But since they can be different we have to convert some users of current->nsproxy first? But that patch was dropped.

Quoted 3 lines

Unsharing of the pid namespace unlike unsharing of other namespaces does not take effect immediately. Instead it affects the children created with fork and clone.

IOW, unshare(CLONE_NEWPID) implicitly affects the subsequent fork(), using the very subtle way.

I have to admit, I can't say I like this very much. OK, if we need this, can't we just put something into, say, signal->flags so that copy_process can check and create the new namespace.

Also. I remember, I already saw something like this and google found my questions. I didn't actually read the new version, perhaps my concerns were already answered...

But what if the task T does unshare(CLONE_NEWPID) and then, say, pthread_create() ? Unless I missed something, the new thread won't be able to see T ?

and, in this case the exiting sub-namespace init also kills its parent?

Quoted 7 lines

OK, suppose it does fork() after unshare(), then another fork(). In this case the second child lives in the same namespace with init created by the 1st fork, but it is not descendant ? This means in particular that if the new init exits, zap_pid_ns_processes()-> do_wait() can't work.

Or not?

And, can't resist. If we are going to change sys_unshare(), I'd like very much to cleanup it first.

Dear all! I promise, I will resend this patch forever until somebody explains me why it is constantly ignored ;)

Oleg.

Read the cover letter in its thread