Bug 127547 - Blocking file lock functions (lockf,flock,fcntl) do not return after timer signal SIGALRM
Summary: Blocking file lock functions (lockf,flock,fcntl) do not return after timer si...
Status: RESOLVED FIXED
Alias: None
Product: SUSE LINUX 10.0
Classification: openSUSE
Component: Kernel (show other bugs)
Version: unspecified
Hardware: i686 SuSE Pro 9.1
: P5 - None : Critical
Target Milestone: ---
Assignee: Andreas Gruenbacher
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-10-11 13:30 UTC by Gerhard Greinecker
Modified: 2005-10-12 15:15 UTC (History)
0 users

See Also:
Found By: Development
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---

Attachments
test program to produce the file lock error (German messages are printed (6.47 KB, application/x-gzip)
2005-10-11 13:32 UTC, Gerhard Greinecker 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Gerhard Greinecker 2005-10-11 13:30:21 UTC 
The file lock functions flock, lockf, fcntl do not return even after the signal
SIGALRM  has been raised and the handler function has been executed. The
functions should return with return value EWOULDBLOCK. This can easily be tested
with the listed function sequence and calling the test program in 2 separate
terminal sessions:
1. signal
2. setitimer
3. fopen
4. fileno
5. fcntl with F_WRLCK and F_SETLKW (or flock or lockf)
6. getchar (to keep the lock in the 1st session; now start the 2nd test).
Comment 1 Gerhard Greinecker 2005-10-11 13:32:14 UTC 
Created attachment 53626 [details]
test program to produce the file lock error (German messages are printed
Comment 2 Hubert Mantel 2005-10-11 15:06:52 UTC 
Jens, I'm not sure if you are the right victim for this one ;)
Anyway, I would expect that this bug is also in the official kernel. If it is a bug.
Comment 3 Chris L Mason 2005-10-11 18:51:13 UTC 
Andreas, please take a look at this one.
Comment 4 Andreas Gruenbacher 2005-10-12 10:55:22 UTC 
I can reproduce this on 10.0, but not with one of our 2.6.5 kernels. fcntl 
should return -1 and set errno to EINTR (and not EWOULDBLOCK as written in 
comment 1) when SIGALRM happens, but the signal is not delivered. Explicitly 
sending a SIGALRM signal has no effect, either. Looking...
Comment 5 Gerhard Greinecker 2005-10-12 14:56:48 UTC 
solved:
different behaviour of the system call 'signal' in linux and various unix
platforms - some use BSD semantics, some others POSIX semantics.
use of 'sigaction' instead of 'signal' allows explicit specification.
Comment 6 Andreas Gruenbacher 2005-10-12 15:02:08 UTC 
Could you please be more specific and explain how the issue appears to be 
fixed from your point of view? Thanks.
Comment 7 Gerhard Greinecker 2005-10-12 15:15:43 UTC 
I replaced the call 'signal' by 'sigaction' and did NOT specify the flag
SA_RESTART, then it works as I expected. I assume that the 'signal' call
internally sets the SA_RESTART under Linux.