Messages in this thread | | | Date | Tue, 15 Apr 2008 20:42:31 +0200 | From | Manfred Spraul <> | Subject | Re: [PATCH 2/2] fix sys_unshare()+SEM_UNDO: perform an implicit CLONE_SYSVSEM in CLONE_NEWIPC |
| |
Serge E. Hallyn wrote: > >> Thus all apps right now call unshare(CLONE_NEWIPC|&~CLONE_SYSVSEM). >> This combination doesn't make much sense. Even worse - it easily causes a >> kernel oops. >> Thus my fix is twofold: >> - add support for unshare(CLONE_SYSVSEM). >> - implicitely add CLONE_SYSVSEM to all calls that set CLONE_NEWIPC. >> > > Right but your fix ignores the fact that you can achieve the same > result as unshare(CLONE_NEWIPC&~CLONE_SYSVSEM) by doing > clone(CLONE_NEWIPC|CLONE_SYSVSEM). > Duh, I overlooked that part. You are right. Hmm - what's the best fix? Implicitely add CLONE_SYSVSEM or return -EINVAL if CLONE_SYSVSEM is not set? I don't care. Could you write a patch? I probably won't have enough time until the next weekend.
>> I have decided against that, it breaks the current ABI. >> And we gain virtually nothing - most if not all unshare users will be >> single threaded apps that do not use sysvsem at all, and even most sysvsem >> users do not use SEM_UNDO. >> > > And most importantly sharing your semundo list but not your sems with > your parent is silly! It's only 99% silly: a task might want to have not-yet undone changes in its parent's namespace. As soon as the task exit, they are undone. Probably the most complex way to implement wait4().
-- Manfred
| |