Messages in this thread | | | Date | Wed, 06 Sep 2000 23:53:46 -0700 | From | George Anzinger <> | Subject | Re: Drivers that potentially leave state as TASK_{UN}INTERRUPTIBLE |
| |
John Levon wrote: > > On Wed, 6 Sep 2000, George Anzinger wrote: > > > John Levon wrote: > > > > > > Am I right ? against test8pre1 > > > > > > Also, is it a bug to not set TASK_{UN}INTERRUPTIBLE before doing a > > > schedule_timeout() ? What will happen ? > > > > > Well, first the "timeout" call will return immediately. Next, when the > > time out actually happens, if the task is not TASK_RUNNING (i.e. it is > > waiting for some other thing) it will wake_up. So the sleep is lost and > > it is possible to have a false wake up (could even wake up a zombie). > > If the actual timeout happens while the task is TASK_RUNNING it is > > ignored. > > > > George > > > > So it seems to be a bug at least in terms of timing. Unfortunately I only > got about 4 replies to the patches that touched 20+ drivers. I suppose I > should just hassle maintainers until they fix it or tell me where I've > gone wrong ... > Actually I was not quite correct. The call to timeout WILL return immediately, however, the timeout code will clean up the timer, so there should be no worry there. It is a bug in that the sleep does not happen as expected. I saw at least one place where there were comments about it not working.. and he did not set the state. For what its worth I think the schedule_timeout() should be changed to __schedule_timeout() and two new time out calls be used {un}interruptible_sleep_on_timeout(), these calls to do the set up of state. In fact the interruptible version already exists. Of course things like select would have to use __schedule_timeout() as they are waiting for any of several events.
George - 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/
| |