Bug 145338

Summary: attach or detach during nanosleep in 32 bit process returns EINVAL instead of EINTR
Product: Red Hat Enterprise Linux 4 Reporter: john yates <jyates>
Component: kernelAssignee: Jason Baron <jbaron>
Status: CLOSED WONTFIX QA Contact:
Severity: high Docs Contact:
Priority: medium    
Version: 4.0CC: jakub, knoel, phansen
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-06-20 16:18:32 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
repro.c, Makefile and shell script to demonstrate correct 64-bit and errant 32-bit behavior none

Description john yates 2005-01-17 16:26:08 UTC 
Description of problem:

(Component is just a guess)

Executing nanosleep from a 32-bit returns wrong value in errno when interrupted 
by a signal (EINVAL instead of EINTR).  For quick reference here is man page 
description:

====

In case of an error or exception, the nanosleep system call returns -1 instead 
of 0 and sets errno to one of the following values:

EINTR 
The pause has been interrupted by a non-blocked signal that was delivered to 
the process. The remaining sleep time has been written into *rem so that the 
process can easily call nanosleep again and continue with the pause. 

EINVAL 
The value in the tv_nsec field was not in the range 0 to 999 999 999 or tv_sec 
was negative. 
  

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


How reproducible:

Run repro.sh from attached archive.

Actual results:

errno is EINVAL

Expected results:

errno should be EINTR

Additional info:
Comment 1 john yates 2005-01-17 16:26:08 UTC 
Created attachment 109867 [details]
repro.c, Makefile and shell script to demonstrate correct 64-bit and errant 32-bit behavior
Comment 2 Jakub Jelinek 2005-01-17 16:56:10 UTC 
*** Bug 145337 has been marked as a duplicate of this bug. ***
Comment 3 Jakub Jelinek 2005-01-17 17:12:15 UTC 
This is a kernel thing, glibc's nanosleep just issues the nanosleep syscall.
Comment 4 john yates 2005-01-17 22:31:10 UTC 
Earlier description is misleading.  The crux of the problem is that
our debugging methodology revolves around spinning in a loop that
pauses briefly in nanosleep so long as a given "spinfile" exists. 
This allows us to attach a debugger before a given context is lost.

The act of attach to a 32 bit process in one of these spin loops
exhibits a bug.  It appears that some aspect of the attach performs an
madvise with a bad 3rd argument (int advice).  This seems to leave an
corrupted errno containing EINVAL instead of the expected EINTR:

  madvise(0xffffda10, 4294957576, 0x6b1ff4) = -1 EINVAL (Invalid argument)
Comment 5 Jiri Pallich 2012-06-20 16:18:32 UTC 
Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. The release for which you requested us to review is now End of Life. 
Please See https://access.redhat.com/support/policy/updates/errata/

If you would like Red Hat to re-consider your feature request for an active release, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue.