no set_current_state() before schedule_timeout() (OSST)

no set_current_state() before schedule_timeout() (OSST)

[Nishanth Aravamudan]

Hi,

In continuing to replace, where appropriate, code with msleep() calls, I 
ran across the following file(s) / function(s), which do not invoke 
set_current_state() before schedule_timeout(), which causes the latter 
to return immediately:

drivers/scsi/osst.c::osst_reposition_and_retry()

If someone could tell me which state (TASK_INTERRUPTIBLE or 
TASK_UNINTERRUPTIBLE) is desired, I can fix this and perhaps replace the 
calls with msleep().

Thanks,
Nish

[PATCH] Re: no set_current_state() before schedule_timeout() (OSST)

[Willem Riede]

On 07/13/2004 01:40:54 PM, Nishanth Aravamudan wrote:
> Hi,
> 
> In continuing to replace, where appropriate, code with msleep() calls, I
> ran across the following file(s) / function(s), which do not invoke
> set_current_state() before schedule_timeout(), which causes the latter
> to return immediately:
> 
> drivers/scsi/osst.c::osst_reposition_and_retry()
> 
> If someone could tell me which state (TASK_INTERRUPTIBLE or
> TASK_UNINTERRUPTIBLE) is desired, I can fix this and perhaps replace the
> calls with msleep().

You're right, there is a set_current_state(TASK_INTERRUPTIBLE) missing.
I don't know why we would want to change to use msleep() though.
Below is the patch to add the missing statement.

James Bottomley, can you apply this patch?

Regards, Willem Riede.

Signed-off-by: Willem Riede <osst@riede.org>

--- linux-2.6.8-rc1/drivers/scsi/osst.c.orig	2004-07-13
18:59:16.026349000 -0400
+++ linux-2.6.8-rc1/drivers/scsi/osst.c	2004-07-13 19:01:58.040719208
-0400
@@ -1555,6 +1555,7 @@
 			debugging = 0;
 		}
 #endif
+		set_current_state(TASK_INTERRUPTIBLE);
 		schedule_timeout(HZ / 10);
 	}
 	printk(KERN_ERR "%s:E: Failed to find valid tape media\n", name);

Re: [Kernel-janitors] [PATCH] Re: no set_current_state() before schedule_timeout() (OSST)

[Nish Aravamudan]

On Tue, 13 Jul 2004 23:07:32 +0000, Willem Riede <osst@riede.org> wrote:
> 
> 
> On 07/13/2004 01:40:54 PM, Nishanth Aravamudan wrote:

<snip>

> > If someone could tell me which state (TASK_INTERRUPTIBLE or
> > TASK_UNINTERRUPTIBLE) is desired, I can fix this and perhaps replace the
> > calls with msleep().
> 
> You're right, there is a set_current_state(TASK_INTERRUPTIBLE) missing.
> I don't know why we would want to change to use msleep() though.

<snip>

The main reason I see for using msleep() instead is if the task should
sleep for at least 100 ms. Using TASK_INTERRUPTIBLE (or really
anything other than msleep()) is not guaranteed to sleep as long as
requested. If that's ok / desired, then I won't convert it, of course.

Thanks,
Nish

Re: [Kernel-janitors] [PATCH] Re: no set_current_state() before schedule_timeout() (OSST)

[Nishanth Aravamudan]

Nish Aravamudan wrote:
> On Tue, 13 Jul 2004 23:07:32 +0000, Willem Riede <osst@riede.org> wrote:
> 
>>
>>On 07/13/2004 01:40:54 PM, Nishanth Aravamudan wrote:
> 
> 
> <snip>
> 
>>>If someone could tell me which state (TASK_INTERRUPTIBLE or
>>>TASK_UNINTERRUPTIBLE) is desired, I can fix this and perhaps replace the
>>>calls with msleep().
>>
>>You're right, there is a set_current_state(TASK_INTERRUPTIBLE) missing.
>>I don't know why we would want to change to use msleep() though.
> 
> 
> <snip>
> 
> The main reason I see for using msleep() instead is if the task should
> sleep for at least 100 ms. Using TASK_INTERRUPTIBLE (or really
> anything other than msleep()) is not guaranteed to sleep as long as
> requested. If that's ok / desired, then I won't convert it, of course.

To be clear, the 100 ms I mention above is specific to this example. In 
general, if the time you want to sleep (and you really want to *sleep* 
for that time) is measureable in msecs, then msleep() is the way to go.

-Nish

Re: [Kernel-janitors] [PATCH] Re: no set_current_state() before schedule_timeout() (OSST)

[Willem Riede]

On 07/13/2004 07:36:01 PM, Nish Aravamudan wrote:
> 
> The main reason I see for using msleep() instead is if the task should
> sleep for at least 100 ms. Using TASK_INTERRUPTIBLE (or really
> anything other than msleep()) is not guaranteed to sleep as long as
> requested. If that's ok / desired, then I won't convert it, of course.

There is no need for such guarantee. The current behavior is OK, by design.

Regards, Willem Riede.