Wait queues and a race condition on 2.2.x

From: Lee Cremeans (leec@gtgi.com)
Date: Wed Sep 20 2000 - 14:47:32 EST


I'm working on a driver for the Hi/fn 7751 encryption chip, and I've run
into a weird problem and I'm not entirely sure how to fix it. The driver
was originally written for NT, but has been broken out into OS-specific and
OS-independent parts, and the Linux-specific part calls code in the
OS-independent part of the driver to process requests. The code I'm working
with is currently doing something like this:

.
.
.
/* send a request to the other part of the driver here */
save_flags(flags);
cli();
interruptible_sleep_on_timeout(callback, HZ) /* 1 second timeout */

restore_flags(flags);

if(timeout == 0) {
        /* We timed out. Abort the request */
        /* cleanup stuff goes here */
          return -EIO;
}
.
.
.

where "callback" is a callback routine that wakes up when the Linux code
gets a response from the other side of the driver.

Now, the problem I'm having is that when I run with about 8 processes using
the driver at once, this part of the code appears to spill over, causing
all the sessions to act like the timeout expired and the other side of the
driver is having problems...but I can use a single session at this point,
and get a request through with no problems. I noticed that in the FreeBSD
version of the code, the original developer set splhigh() (pretty much the
equivalent of cli()) and tsleep()/wakeup(), which allow you to give a
context along with the request so that the wrong queue entry doesn't get
pulled; in FreeBSD, the problem doesn't happen. My theory is that, with
many processes hitting the card at once, the queue is getting overwhelmed
somehow. Am I handling this correctly, and more importantly, is there a
better way to do what I'm doing?

-lee
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 21:00:23 EST