Bug 250400

Summary: Profiling signals generated by itimer only delivered to the main thread
Product: Red Hat Enterprise Linux 4 Reporter: Neil Campbell <neilc>
Component: kernelAssignee: Roland McGrath <roland>
Status: CLOSED NEXTRELEASE QA Contact: Martin Jenner <mjenner>
Severity: low Docs Contact:
Priority: low    
Version: 4.5CC: jbaron
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-09-13 18:31:57 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Test case which shows the behaviour described. none

Description Neil Campbell 2007-08-01 12:15:32 UTC 
Description of problem:

Profiling signals generated by itimer are not delivered to threads other than
the main thread.

Version-Release number of selected component (if applicable):

RHEL4.5, kernel 2.6.9-55.ELsmp.  Tested on i386 and ppc64 platforms.  Also
occurs in RHEL4.4.


How reproducible:
Easily.

Steps to Reproduce:
1. Compile attached test case: g++ setitimer.cc -o setitimer -lpthread
2. Run the test case: ./setitimer
3. Observe lack of profiling signals delivered to child thread.
  
Actual results:

No profiling signals are sent to the newly created thread.  The new thread is
also unable to get the itimer settings.

$ ./setitimer
Main thread is 10331
itval: 0, 0, 0, 0
$


Expected results:

The new thread, which is using CPU time, should receive profiling signals, eg:

$ ./setitimer
itval: 0, 4000, 0, 8000
4958: signal received
4958: signal received
4958: signal received
...
$

Additional info:

I've tried the test case on more recent kernel versions (2.6.16, 2.6.20) and it
works as expected, ie all executing threads receive timer signals.
Comment 1 Neil Campbell 2007-08-01 12:15:32 UTC 
Created attachment 160407 [details]
Test case which shows the behaviour described.
Comment 2 Roland McGrath 2007-09-13 18:31:57 UTC 
These are the expected semantics in RHEL4, setitimer et al are per-thread.
This is not the POSIX semantics, but that is how Linux always behaved up to that
time.  The semantics of setitimer et al have changed in later kernels to conform
to POSIX, and RHEL5 does behave correctly in this regard.  The semantics of
RHEL4 and older systems will not change in update versions.