Bug 127547

Summary:	Blocking file lock functions (lockf,flock,fcntl) do not return after timer signal SIGALRM
Product:	[openSUSE] SUSE LINUX 10.0	Reporter:	Gerhard Greinecker <boi>
Component:	Kernel	Assignee:	Andreas Gruenbacher <agruen>
Status:	RESOLVED FIXED	QA Contact:	E-mail List <qa-bugs>
Severity:	Critical
Priority:	P5 - None
Version:	unspecified
Target Milestone:	---
Hardware:	i686
OS:	SuSE Pro 9.1
Whiteboard:
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

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.