Created attachment 324066 [details] setpriority.tar.gz Description of Problem: Escalating a clone of IT#175599(BZ#455251). FJ is asking for us to put information to 5.4 Release Notes. When the nice value of multithreaded process is set by using the renice(), this function sets the nice value to only main thread. This function just uses the setpriority(). The "POSIX Programmer's Manual" defines setpriority() as follows: The nice value set with setpriority() shall be applied to the process. If the process is multi-threaded, the nice value shall affect all sys- tem scope threads in the process. And the "Linux Programmer's Manual" defines setpriority() as follows: The scheduling priority of the process, process group, or user, as indicated by which and who is obtained with the getpriority() call and set with the setpriority() call. Both manuals define setpriority() shall set the nice value to all threads of the process, but RHEL5.2 kernel seems not to conform with them. This problem was previously found on RHEL4 and I reported it as IT175599. Since it concluded not to be fixed until RHEL6 but to write a note in release note for it, I request another note for RHEL5, too. Version-Release number of selected component: Red Hat Enterprise Linux Version Number: 5 Release Number: 2 Architecture: Kernel Version: 2.6.18-92.el5 Related Package Version: Related Middleware / Application: Drivers or hardware or architecture dependency: None How reproducible: Always Step to Reproduce: 1. Extract the archive file(setpriority.tar.gz). The following files are extracted. Makefile setpriority.c 2. Compile the test program. $ make 3. Change root user. $ su 4. Run the test program. # ./setpriority Actual Results: The setpriority() sets the nice value to only main thread as follws: # ./setpriority start test program TID:5619 priority 0 TID:5620 priority 0 TID:5621 priority 0 TID:5622 priority 0 TID:5623 priority 0 setpriority(PRIO_PROCESS, 5619, -10) TID:5619 priority -10 TID:5620 priority 0 TID:5621 priority 0 TID:5622 priority 0 TID:5623 priority 0 Expected Results: The processing of setpriority() is corresponding to the explanation of the manual. Summary of actions taken to resolve issue: Location of diagnostic data: Hardware configuration: Model: PRIMERGY TX150 S5 CPU: 2 Memory: 6G Hardware Component Information: None Configuration info: None Guest Configuration Info: None Business Impact: Target Release : 5.4 Errata Request : none Hotfix Request : none Additional Info: I attached test program and sosreport.
Created attachment 324067 [details] sosreport
That's a kernel bug, not glibc. See http://lkml.org/lkml/2008/9/1/157 for a patch and follow-up thread. That said, I'm not sure if it is desirable to change it in RHEL5 updates, as it is pretty important behavior change.
per upstream discussion, http://lkml.org/lkml/2008/9/10/122, the patch is not in 2.6.29-rc2; due to it may break the old behavior; or any applications that work around the issue.
Updating PM score.
A release note is all that is needed.
Release note added. If any revisions are required, please set the "requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: In Red Hat Enterprise Linux 5, invoking the kernel system call "setpriority()" with a "which" parameter of type "PRIO_PROCESS" does not set the priority of child threads.