Re: System V semaphore bug in kernel 2.6

[Manfred Spraul]

Michael Kerrisk wrote:

> Hello Manfred, Alan,
>
> I assume you are still the relevant people to know about 
> this nowadays...
>
> Somewhere in the reworking of the System V semaphore code 
> (ipc/sem.c or nearby) in Linux 2.6, a bug appears to have 
> been introduced.  
>
>  
ipc/sem.c. The change that now semaphores are actively given to the 
waiting task broke your test.

What happens is:

child 3 does a semaphore operation. It succeeds. update_queue is called:
- try_atomic_semop checks if it can wake up child 2. Answer: No.
- try_atomic_semop(): kernel checks if it can wake up child 1. Answer: Yes.

Bug: It must now check again if there is a thread that is waiting for 
semaphore value==0. This check is now missing. In 2.4, there was another 
round of update_queue calls just before child 1 returns to user space. 
That call then wakes up child 1. This call was removed.

One approach to fix that is a loop in update_queue: If a 
try_atomic_semop call from within update_queue modified the array, then 
check again from the beginning of the queue.

What do you think? I'll write a patch.

--
   Manfred
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/