Messages in this thread | | | Date | Mon, 31 Mar 2008 18:14:47 +0200 | From | Manfred Spraul <> | Subject | Re: [RFC, PATCH] fix SEM_UNDO with namespaces |
| |
Pavel Emelyanov wrote: > Manfred Spraul wrote: > >> Hi, >> >> the attached patch should fix the combination of CLONE_NEWIPC with >> shared sysv undo structures (the common case, just >> sys_unshare(CLONE_NEWIPC)): >> lookup_undo() now locates the undo array based on both semid and the >> namespace pointer. >> > > If you start using any IPC object and then call unshare with CLONE_NEWIPC, > then it's your problem, but not the kernel. > The result is a kernel memory corruption, and kernel memory corruptions are always the kernel's problem.
The code assumed that a semaphore id is globally unique. With namespaces, this is not true anymore. If two semaphore arrays exist with the same id, but different sizes, then semops will cause memory corruptions: The undo structure contains one element for each semaphore, thus the semop will write behind the end of the memory allocation.
> 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.
-- Manfred
| |