"Manfred Spraul" <manfreds@colorfullife.com> writes:
> some callers of sleep_on() do that to reduce the race:
>
> spin_unlock(&io_request_lock);
> <<<<<< wake-up could arrive.
> sleep_on(&wait_queue);
> spin_lock_irq(&io_request_lock);
>
> Actually I would prefer if we could add a big assert to sleep_on() in
> 2.5.early:
> sleep_on is a very simple function with a nice name, and thus many drivers
> use it without proper locking [global_cli or lock_kernel].
Speaking of this sleep_on+unlock race that is still present in a few drivers,
how about adding sleep_on_unlock(wait_q, lock) that would unlock the supplied
lock at the right time, after adding the process to the wait queue? This
race used to be present in the scsi code and has been fixed with the folowing
(comments removed):
if (wait) {
DECLARE_WAITQUEUE(wait, current);
add_wait_queue(&device->scpnt_wait, &wait);
if( interruptable ) {
set_current_state(TASK_INTERRUPTIBLE);
} else {
set_current_state(TASK_UNINTERRUPTIBLE);
}
spin_unlock_irqrestore(&device_request_lock, flags);
schedule();
...
That's essentially what sleep_on_unlock() would do and problematic drivers
should be able to adopt easily. Requiring global_cli or lock_kernel to sleep
safely seems unnecesarily expensive.
-- Dimitris Michailidis dimitris@engr.sgi.com- 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/
This archive was generated by hypermail 2b29 : Thu Mar 23 2000 - 21:00:37 EST