Bug 1826 - thread creation attributes don't match documentation
Summary: thread creation attributes don't match documentation
Status: RESOLVED INVALID
Alias: None
Product: glibc
Classification: Unclassified
Component: linuxthreads (show other bugs)
Version: 2.3.4
: P2 normal
Target Milestone: ---
Assignee: drow@false.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-11-07 16:13 UTC by Chris Friesen
Modified: 2016-05-20 19:44 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:
fweimer: security-


Attachments
testcase for bug (627 bytes, text/plain)
2005-11-07 17:50 UTC, Chris Friesen
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Friesen 2005-11-07 16:13:31 UTC
1) The man pages for pthread_create() say that if you don't specify "attr", then
the default scheduler class is used. The man page for pthread_attr_init()
specifies that the default sched policy is SCHED_OTHER.

However, if you put the original thread into the SCHED_RR class and give it a
nonzero priority, then call pthread_create() with "attr" of NULL, the new thread
will end up with the same scheduler parameters as the thread that created it.
This violates the stated semantics.

2) The default attribute for the "inheritsched" attribute is supposed to be that
you do not inherit the scheduler parameters.  This would seem to imply that
ATTR_FLAG_NOTINHERITSCHED should be *set* by default. However, based on the code
pthread_attr_init() simply sets everything to zero, then sets the guardsize member.

This means that for me to specify scheduler attributes I have to explicitly call
pthread_attr_setinheritsched() with PTHREAD_EXPLICIT_SCHED even though it's
supposed to be the default.
Comment 1 Dwayne Grant McConnell 2005-11-07 17:14:10 UTC
I'm takin a look at this.
Comment 2 Chris Friesen 2005-11-07 17:50:54 UTC
Created attachment 748 [details]
testcase for bug

This testcase should be run as root, and will verify the behaviour listed in
the bug.
Comment 3 Jakub Jelinek 2005-11-07 17:54:23 UTC
You shouldn't be looking into LinuxThreads manual pages when you are running
NPTL.  Use POSIX manual pages or standard instead.
Comment 4 Chris Friesen 2005-11-07 17:55:35 UTC
The bug was tested on ppc64 kernel, with ppc userpace, and on i386.

It has been verified to exist on the following distros:

Yellowdog 4 with libc 2.3.3
Windriver distro with libc 2.3.4
Mandrake 10.0 with libc 2.3.3
Comment 5 Daniel Jacobowitz 2005-11-07 17:59:59 UTC
(In reply to comment #3)
> You shouldn't be looking into LinuxThreads manual pages when you are running
> NPTL.  Use POSIX manual pages or standard instead.

Chris, can you confirm whether you are using LinuxThreads or NPTL?  The bug is
filed against LinuxThreads but at least two of the distributions you've listed
use NPTL by default.
Comment 6 Chris Friesen 2005-11-07 18:26:08 UTC
(In reply to comment #3)
> You shouldn't be looking into LinuxThreads manual pages when you are running
> NPTL.  Use POSIX manual pages or standard instead.

Crap.

Apparently two separate distros used NPTL but kept the older man pages.  The
very latest man pages do not actually specify a default value for any of the
three attributes involved (inheritsched, policy, or priority).

I guess there isn't an issue with libc, rather with the distros in question.
Comment 7 Chris Friesen 2005-11-07 18:27:55 UTC
Sorry, I was using NPTL...guess I didn't notice the distinction.

Looks like it was a distro issue rather than a libc one.
Comment 8 Dwayne Grant McConnell 2005-11-07 19:01:02 UTC
I'm marking this INVALID because of the comments above and because I did not see
anything in the Open Group spec that contradicted the current behavior. As
mentioned above this appears to be a distro specific issue with the documentation.