Messages in this thread | | | Subject | Re: sleep_on, wake_up question | Date | Thu, 30 Dec 1999 14:54:50 +0000 (GMT) | From | Alan Cox <> |
| |
> > 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/
| |