Messages in this thread | | | From | (Eric W. Biederman) | Subject | Re: [RFC, PATCH] fix SEM_UNDO with namespaces | Date | Tue, 01 Apr 2008 09:25:20 -0600 |
| |
Pavel Emelyanov <xemul@openvz.org> writes: >>> I agree, that we should probably destroy this one when the task calls >>> unshare, but trying to keep this list relevant is useless. >>> >> A very tricky question: Let's assume we have a process with two threads. >> The undo structure is shared, as per opengroup standard. >> Now one thread calls unshare(CLONE_NEWIPC). What should happen? We >> cannot destroy the undo structure, the other thread might be still >> interested in it. >> If we allow sys_unshare() for multithreaded processes with CLONE_NEWIPC >> and without CLONE_SYSVSEM, then we must handle this case. > > Hm... I'd simply disable creating any new namespaces for threads. > I think other namespaces developers agree with me. Serge, Suka, Eric > what do you think?
I almost agree. sys_unshare() in a multithreaded process breaks all kinds of user space libs. So you can only reasonably look at the problem as what we do with linux tasks that share some things and not others. The posix/opengroup notion of processes and threads are a distraction.
In this case requiring it appears that to require unsharing both CLONE_SYSVSEM and CLONE_NEWIPC at the same time. (i.e. unshare of CLONE_SYSVSEM should fail if CLONE_NEWIPC is not also specified).
Then to make it work we make unshare of SYSVSEM succeed when it is not shared.
This looks like about a 5 line patch or two.
The effect is because we don't support unsharing of SYSVSEM currently we don't support a threaded process unsharing the ipc namespace.
Eric
| |