Re: sleep_on, wake_up question

Alan Cox (alan@lxorguk.ukuu.org.uk)
Thu, 30 Dec 1999 14:54:50 +0000 (GMT)


> > It's possible that the PC will be interrupted (by anything) just prior to
> > the sleep_on call in my_ioctl, and eventually, the adapter may even
> > complete its work (and call wake_up) before the sleep_on function was even
> > reached. In a heavily loaded system, this possibility is more than
> > theoretical. In this case, it appears that the calling process may forever
> > hang in sleep_on. Help? Am I missing something here?
>
> There is more at work than your code implies. If the interrupt occurs
> instantly, before your call to interruptible_sleep_on(), the call will
> return immediately. It works. I have many drivers using this technique
> and they have never missed a beat.

Its luck on your part then. There is no provision in the system for handling
that race using interruptible_sleep_on, because you can construct multiple
correct solutions without having to hack the kernel up

Hints

1. allocate a semaphore on the stack
set up for irq
do hardware stuff
down_interruptible(&sem)
if(interrupted by signal)
{
job->sem=NULL;
clean up completely (including stopping an irq hitting sem)
return failed)
}
Ok

In the irq do an if(job->sem) up(job->sem);

The semaphores are counting so do the right thing if there is an ordering
race.

2. Use add/remove wait queue so that the race leaves the task woken
if it beats the sleep begin

3. Use cli to lock around the contentious areas (ugly)

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