> I just played with this and if you make the semantics of unshare(CLONE_NEWPID)
> to be that you become the idle task aka pid 0, and not the init task pid 1 the
> implementation is trivial.
This is not ... handy - if after enter you have pid 0 you obviously
can't perform 2 parallel enters. The way I see it:
As far as the numbers reported to the userspace are concerned:
1. task, that enters is still visible by its old parent by old pid
2. task, that enters gets some pid within the entering namespace
and reports its parent pid to have pid 1 (init obviously doesn't
care)
3. we _can_ try to allocate new pid equal to the old one so that
glibc stays happy
As far as the pointers are concerned:
1. parent pointer doesn't change
2. task_pid(tsk) one (i.e. struct pid * one) _can_ change if
a) we don't allow threads enter (de_thread problem is handeled)
b) we don't allow leave the group/session, i.e. check, that there
is the only one task that enters lives in its pgid/sid
c) we wait for the quiescent state to pass by before destroying
the old pid to handle race with sys_kill()
Thoughts/questions? ("This is a nasty problem" answer is not acceptable,
the real code problems/races please)
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
