[ ssic-linux-Bugs-1984656 ] semaphore undo count sometimes screws up

Bugs item #1984656, was opened at 2008-06-04 18:41
Message generated for change (Comment added) made by hughesj
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=405834&aid=1984656&group_id=32541

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IPC
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: John Hughes (hughesj)
Assigned to: Nobody/Anonymous (nobody)
Summary: semaphore undo count sometimes screws up

Initial Comment:
Testing alsa applications, which use the rather strange idiom that:

DOWN(sem) = SEMOP (wait for semaphore to go to zero, increment semaphore)

UP(sem) = SEMOP (decrement semaphore)

we find that sometimes the semaphore is left at 1 when a process exits, which should be impossible as all operations are done with the SEM_UNDO flag set.

Tracing the ssi_semexit code shows an adjustment of +1 being applied to a semaphore with value 0, which should also be impossible - with this idiom the undo should either be -1 or zero

Argument:

The semaphore is initially zero.  If an application does a DOWN() call then it will have an adjustment of -1.  When it does an UP it will have an adjustment of 0.




----------------------------------------------------------------------

>Comment By: John Hughes (hughesj)
Date: 2008-06-05 21:52

Message:
Logged In: YES 
user_id=166336
Originator: YES

so, here's what happens.

In the base code when a new proc is cloned it either shares it's semaphore
undo list - a pthread_create, or it makes a new one - a fork.

In the OpenSSI code we only know how to deal with fork - we use the pid to
find the undo list.

Here's a test program that shows the problem - when run on a non-openssi
system the semaphore val is zero when the subprocess exits (because it's 10
subthreads shared an undo list).  When run on an  OpenSSI system the
semaphore value is left at 9 because each thread gets its own undo list,
only one of which is used at process exit.

It looks like this is going to take a bit of re-architeching to fix.

File Added: semundo.c

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=405834&aid=1984656&group_id=32541

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php