Re: Drivers that potentially leave state as TASK_{UN}INTERRUPTIBLE
On Wed, 6 Sep 2000, George Anzinger wrote: > 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. This was driver/sound/maestro.c btw john -- "Premature generalization is the root of all evil." - Karl Fogel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Drivers that potentially leave state as TASK_{UN}INTERRUPTIBLE
On Wed, 6 Sep 2000, George Anzinger wrote: 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. This was driver/sound/maestro.c btw john -- "Premature generalization is the root of all evil." - Karl Fogel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Drivers that potentially leave state as TASK_{UN}INTERRUPTIBLE
You can ran into problems using schedule_timeout() in a block device request function under 2.4. This can be demonstrated by starting some I/O intensive tasks to your block device and running sync in another task. Eventually the block layer will lock up. This can be fixed by creating a kernel thread per flash device to handle the I/O requests. Within the thread schedule_timeout() works fine. This solution also works under 2.2 and 2.0.38 [EMAIL PROTECTED] (David Woodhouse) said: > [EMAIL PROTECTED] said: > > 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 quite happy calling schedule_timeout in the flash drivers > without changing current->state. I'm waiting to something to happen, and > just to be considerate, I'm asking to be put to sleep for the 'expected' > amount of time for whatever's happening. If there's other stuff on the run > queue, it won't return immediately, will it? If there isn't other stuff on > the run queue, I'll just busy wait till the flash chip's finished. > > Otherwise, it would be TASK_UNINTERRUPTIBLE. -- __O Fireplug - a Lineo company_-\<,_ PGP Fingerprint: 28 E2 A0 15 99 62 9A 00 (_)/ (_) 88 EC A3 EE 2D 1C 15 68 Stuart Lynne <[EMAIL PROTECTED]> www.lineo.com 604-461-7532 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Drivers that potentially leave state as TASK_{UN}INTERRUPTIBLE
David Woodhouse wrote: > > [EMAIL PROTECTED] said: > > 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 quite happy calling schedule_timeout in the flash drivers > without changing current->state. I'm waiting to something to happen, and > just to be considerate, I'm asking to be put to sleep for the 'expected' > amount of time for whatever's happening. If there's other stuff on the run > queue, it won't return immediately, will it? It most likely will return immediately. The only case it would not is if, while you were running: A tick happened and some other task in the run queue then had a higher count of remaining ticks, or Something event happened to cause the system to want to run some other task (i.e. need_resched is set) In no case will the system wait for anything related to the time you send to schedule_timeout() (which, I think should be called something like xxx_sleep(). >If there isn't other stuff on > the run queue, I'll just busy wait till the flash chip's finished. No you will _almost always_ busy wait. > > Otherwise, it would be TASK_UNINTERRUPTIBLE. UNINTERRUPTIBLE refers to being open to signals. A task waiting UNINTERRUPTIBLE can not be killed (or otherwise signaled) while it is waiting. Signals that come in against the task are just queued until the task allows them to be recognized (by exiting to user land or explicitly calling signal delivery (which very few code paths do)). By waiting INTERRUPTIBLE, the system will wake_up() the task when a signal is posted against it. The task still has to respond to it in one of the above two ways. For what it is worth, I think the system needs a "deliver_signal()" function just for this. I think that this function should have: a.) A "task being killed" call back function, so callers can clean up if the call is not going to return, but instead is killing the task. This would allow drivers to test for being killed as opposed to just being handed some other relatively unimportant signal and to clean up their act if needed. b.) An indication (return value) that tells if a user handler was called. George - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
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 [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Drivers that potentially leave state as TASK_{UN}INTERRUPTIBLE
David Woodhouse wrote: [EMAIL PROTECTED] said: 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 quite happy calling schedule_timeout in the flash drivers without changing current-state. I'm waiting to something to happen, and just to be considerate, I'm asking to be put to sleep for the 'expected' amount of time for whatever's happening. If there's other stuff on the run queue, it won't return immediately, will it? It most likely will return immediately. The only case it would not is if, while you were running: A tick happened and some other task in the run queue then had a higher count of remaining ticks, or Something event happened to cause the system to want to run some other task (i.e. need_resched is set) In no case will the system wait for anything related to the time you send to schedule_timeout() (which, I think should be called something like xxx_sleep(). If there isn't other stuff on the run queue, I'll just busy wait till the flash chip's finished. No you will _almost always_ busy wait. Otherwise, it would be TASK_UNINTERRUPTIBLE. UNINTERRUPTIBLE refers to being open to signals. A task waiting UNINTERRUPTIBLE can not be killed (or otherwise signaled) while it is waiting. Signals that come in against the task are just queued until the task allows them to be recognized (by exiting to user land or explicitly calling signal delivery (which very few code paths do)). By waiting INTERRUPTIBLE, the system will wake_up() the task when a signal is posted against it. The task still has to respond to it in one of the above two ways. For what it is worth, I think the system needs a "deliver_signal()" function just for this. I think that this function should have: a.) A "task being killed" call back function, so callers can clean up if the call is not going to return, but instead is killing the task. This would allow drivers to test for being killed as opposed to just being handed some other relatively unimportant signal and to clean up their act if needed. b.) An indication (return value) that tells if a user handler was called. George - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Drivers that potentially leave state as TASK_{UN}INTERRUPTIBLE
You can ran into problems using schedule_timeout() in a block device request function under 2.4. This can be demonstrated by starting some I/O intensive tasks to your block device and running sync in another task. Eventually the block layer will lock up. This can be fixed by creating a kernel thread per flash device to handle the I/O requests. Within the thread schedule_timeout() works fine. This solution also works under 2.2 and 2.0.38 [EMAIL PROTECTED] (David Woodhouse) said: [EMAIL PROTECTED] said: 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 quite happy calling schedule_timeout in the flash drivers without changing current-state. I'm waiting to something to happen, and just to be considerate, I'm asking to be put to sleep for the 'expected' amount of time for whatever's happening. If there's other stuff on the run queue, it won't return immediately, will it? If there isn't other stuff on the run queue, I'll just busy wait till the flash chip's finished. Otherwise, it would be TASK_UNINTERRUPTIBLE. -- __O Fireplug - a Lineo company_-\,_ PGP Fingerprint: 28 E2 A0 15 99 62 9A 00 (_)/ (_) 88 EC A3 EE 2D 1C 15 68 Stuart Lynne [EMAIL PROTECTED] www.lineo.com 604-461-7532 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Drivers that potentially leave state as TASK_{UN}INTERRUPTIBLE
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 ...
john
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Drivers that potentially leave state as TASK_{UN}INTERRUPTIBLE
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Drivers that potentially leave state as TASK_{UN}INTERRUPTIBLE
Am I right ? against test8pre1
Also, is it a bug to not set TASK_{UN}INTERRUPTIBLE before doing a
schedule_timeout() ? What will happen ?
thanks
john
--- drivers/pcmcia/yenta.c Fri Aug 11 00:21:32 2000
+++ drivers/pcmcia/yenta.c.new Fri Sep 1 02:42:55 2000
@@ -574,6 +574,7 @@
schedule_timeout(HZ);
remove_wait_queue(>wait, );
} while (!signal_pending(current));
+ set_current_state(TASK_RUNNING);
MOD_DEC_USE_COUNT;
return 0;
}
--- drivers/usb/storage/transport.c Wed Aug 30 18:46:53 2000
+++ drivers/usb/storage/transport.c.new Fri Sep 1 03:14:07 2000
@@ -419,6 +419,7 @@
up(&(us->current_urb_sem));
remove_wait_queue(, );
kfree(dr);
+ set_current_state(TASK_RUNNING);
return status;
}
@@ -472,6 +473,7 @@
/* something went wrong */
up(&(us->current_urb_sem));
remove_wait_queue(, );
+ set_current_state(TASK_RUNNING);
return status;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Drivers that potentially leave state as TASK_{UN}INTERRUPTIBLE
Am I right ? against test8pre1
Also, is it a bug to not set TASK_{UN}INTERRUPTIBLE before doing a
schedule_timeout() ? What will happen ?
thanks
john
--- drivers/pcmcia/yenta.c Fri Aug 11 00:21:32 2000
+++ drivers/pcmcia/yenta.c.new Fri Sep 1 02:42:55 2000
@@ -574,6 +574,7 @@
schedule_timeout(HZ);
remove_wait_queue(socket-wait, wait);
} while (!signal_pending(current));
+ set_current_state(TASK_RUNNING);
MOD_DEC_USE_COUNT;
return 0;
}
--- drivers/usb/storage/transport.c Wed Aug 30 18:46:53 2000
+++ drivers/usb/storage/transport.c.new Fri Sep 1 03:14:07 2000
@@ -419,6 +419,7 @@
up((us-current_urb_sem));
remove_wait_queue(wqh, wait);
kfree(dr);
+ set_current_state(TASK_RUNNING);
return status;
}
@@ -472,6 +473,7 @@
/* something went wrong */
up((us-current_urb_sem));
remove_wait_queue(wqh, wait);
+ set_current_state(TASK_RUNNING);
return status;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
