[429] in Pthreads mailing list archive
timing problem in fd_check_entry
daemon@ATHENA.MIT.EDU (Larry V. Streepy, Jr.)
Sun Sep 29 12:36:44 1996
Date: Sun, 29 Sep 1996 10:27:33 -0600
From: "Larry V. Streepy, Jr." <streepy@healthcare.com>
To: pthreads@MIT.EDU
All,
In trying to understand the file table locking methods (so I can
implement pthread_cancel), I think I found a potential timing problem.
fd_lock calls fd_check_entry to ensure that the fd_table entry indexed
is non-NULL. If so, it continues with the operation. However, here's
the code to fd_check_entry:
int fd_check_entry(unsigned int entry)
{
int ret = OK;
pthread_mutex_lock(&fd_table_mutex);
if (entry < dtablesize) {
if (fd_table[entry] == NULL) {
if (fd_init_entry(entry)) {
SET_ERRNO(EBADF);
ret = -EBADF;
}
}
} else {
SET_ERRNO(EBADF);
ret = -EBADF;
}
pthread_mutex_unlock(&fd_table_mutex);
return(ret);
}
Notice that it obtains the fd_table_mutex, performs the checks, unlocks
the mutex, and then returns. Since the table mutex has been unlocked,
another thread could run and play with the table entry just checked
before the caller of fd_check_entry gets to run again.
Now, I don't know the internals of the fd code well enough to know if
this can happen (I know the timing issue exists, I don't know if some
operation in thread 'x' could make the entry NULL while an operation in
thread 'y' is trying to lock it).
Can someone with detailed knowledge of the fd core code let me know if
this timing problem can actually manifest itself, or if the underlying
assumptions of the code prevent any real problems.
It seems that fd_check_entry is only called from three places: fd_init,
fd_allocate, and fd_lock. So, fixing the timing issue shouldn't be
hard, if it's needed.
--
Larry V. Streepy, Jr.
Chief Technical Officer, Healthcare Communications, Inc.
mailto:streepy@healthcare.com
(214) 851-7033 (Dallas Main #)
(970) 626-5028 (My office #) (970) 626-4425 (Fax)
