Red Hat Bugzilla – Bug 63468
ttylock / ttyunlock occassionally incorrectly return error
Last modified: 2007-04-18 12:41:59 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020401
Description of problem:
the ttylock/ttyunlock routines of baudboy.h will incorrectly
return an error occassionally. Specifically, if the fork/execv, and the
subsequent execution of lockdev happen, and lockdev exits _BEFORE_ the waitpid
call of baudboy's "doit()", then the waitpid() will see a -1 return, with an
error code of ECHILD.
The end result is that the caller (that called ttylock/ttyunlock) will see a
false error return when infact the ttylock/ttyunlock succeeded.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
attached is a simple c program which loops and does ttylock() / ttyunlock() will
to compile: cc -o foo foo.c
then, as root: chown uucp.uucp foo; chmod 6555 foo
then as normal user: ./foo
Actual Results: generally several times out of the 10,000 loop lockdev will
finish and exit BEFORE the waitpid is started, and then waitpid will see an
error of -1 (with errno of ECHILD).
Expected Results: false errors should not occur
Created attachment 53787 [details]
sample program which demonstrates failure
(assigned it to JBJ as he was the one adding baudboy)
Created attachment 54324 [details]
new SRPM with patch
The problem is that under some scheduling conditions, it is possible for
the fork/execv and exec'd process to run to completion before the fork()
returns. Whenever that happens, the return status is lost (because the
installed signal handler sets SIGCHLD to SIG_IGN).
The attached fix corrects ths problem by installing a signal handler with the
intent purpose of catching the return status BEFORE the fork(), and then waits
around for the return status (which might be ready when the fork completes).
Note: this is the same problem as 62394, but I couldn't get anyone to
look at 62394 so I refiled it under lockdev (after tracking the bug to lockdev).
Your signal patch should be in lockdev-1.0.0-19.
Thanks again for doing the heavy lifting.
*** Bug 62394 has been marked as a duplicate of this bug. ***