Bug 128082 - smeop() problem occurring with multi-threaded application
smeop() problem occurring with multi-threaded application
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
3.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ernie Petrides
Brian Brock
http://www.ussg.iu.edu/hypermail/linu...
:
: 104575 107784 (view as bug list)
Depends On:
Blocks: 133089
  Show dependency treegraph
 
Reported: 2004-07-17 03:44 EDT by Alexandre Oliva
Modified: 2007-11-30 17:07 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-08 20:27:59 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Test program that exposes the problem, copied from the given URL (2.10 KB, text/plain)
2004-07-17 03:53 EDT, Alexandre Oliva
no flags Details

  None (edit)
Description Alexandre Oliva 2004-07-17 03:44:06 EDT
Semaphore posts are only supposed to be undone when the entire
processe exists, not when the posting thread exists.  I'll attach a
program that demonstrates the problem.

FWIW, the test program works on FC2, since kenrel 2.6 has a variant of
the semundo patch in the URL above.  The patch that made it to 2.6
uses the CLONE_SYSVSEM flag to tell the kernel to use the same
semaphore group for the cloned process, and NPTL passes this flag to
clone.  Linuxthreads doesn't, but if I change clone there to pass the
same flag, it works with Linuxthreads as well.

On RHEL3, the flag is passed to the clone syscall, but it has no
effect, because the kernel doesn't have the semundo patch.  This might
be because the patch actually changes a pointer in task_struct,
breaking the ABI.  Any chance we could backport such a patch anyway?
Comment 2 Alexandre Oliva 2004-07-17 03:53:12 EDT
Created attachment 101994 [details]
Test program that exposes the problem, copied from the given URL

the test program's output SHOULD look like:

Waiter, pid = 11490
Poster, pid = 11490, posting
Poster posted
Poster exiting
Waiter waiting, pid = 11490
Waiter done waiting

The Incorrect output on RHEL3U2 with NPTL is:

Waiter, pid = 712
Poster, pid = 712, posting
Poster posted
Poster exiting
Waiter waiting, pid = 712

with Linuxthreads, the only difference is that different threads print
different pids.
Comment 3 Ernie Petrides 2004-07-22 18:51:16 EDT
Other bugzilla reports on this problem are 104575 and 107784.  I'm
reassigning this to myself in case we might have an opportunity to
fix this with a future relaxation of our Kernel Module Interface
compatibility policy.  (Correcting this problem requires a change
to the "task_struct", which would break KMI compat in a major way.)
Comment 4 Ernie Petrides 2004-07-22 18:53:48 EDT
*** Bug 104575 has been marked as a duplicate of this bug. ***
Comment 5 Ernie Petrides 2004-07-22 18:54:30 EDT
*** Bug 107784 has been marked as a duplicate of this bug. ***
Comment 6 Ernie Petrides 2005-09-08 20:27:59 EDT
This will never be fixed in RHEL3 due to KMI (kABI) compatibility constraints.

Note You need to log in before you can comment on or make changes to this bug.