Re: interruptible_sleep_on, interrupts and device drivers

[Gabriele Brugnoni <news@dveprojects.com>]

Arjan van de Ven wrote:

> 
> don't.
> 
> interruptible_sleep_on() is a broken interface (see the comments in the
> header) and should not be used in any new code (where "new" is "since
> the year 2000" :)
> 
> Just use the wait_event() interfaces .... or just a simple semaphore
> even if what you want to do is simple and performance isn't too
> critical.
> 

OK, i'll not use, but the kernel has a lot of device drivers using it, that 
may present the problem explained in my message.

In my code i've try the following:

		save_flags(flags); cli();
		if( !rs.txdone ) {
			if( arg < 0 ) arg = rs.ttimeout;
			if( arg > 0 )
				interruptible_sleep_on_timeout ( &rs.txwait, arg );
			else
				interruptible_sleep_on ( &rs.txwait );
		}
		restore_flags(flags);
		return rs.txdone;

Before testing the flag, interrupt are closed and if the TX is not terminated, 
the interruptible_sleep_on_timeout will be called with interrupt DISABLED. 
This is not a problem, because the scheduler will switch to another process, 
and the new process will enable again the IRQ. When the scheduler will give 
back the control to my process, it will continue with interrupt disabled, and 
will be reenabled before exit.
This seems to work very fine.

Calling the waiting function with IRQ enabled may expose the device driver to 
the risk of infinite wait (until a signal, obvious).


Thanks
Gabriele