Arthur Naseef wrote:
>
> Andrew:
>
> Excellent. I will look at the 2.4 sources.
>
> In addition to the TASK_ZOMBIE issue you mention, I believe there
> is an issue of false termination of wait queues. Consider this:
>
> - Task places itself on a wait queue
> - Calls schedule()
> - tq_scheduler function does the same
>
> Now, there are two events which could place the task in TASK_RUNNING
> and no clear way to differentiate. And, since most of the kernel
> code does not check that the wait condition was actually met, this
> could lead to all types of problems, right?
>
Yes. The situation where one task is on two waitqueues
is rare, but does happen. And yes, there is code out there
which does a bare schedule() and *assumes* that once the
schedule has returned, the thing it was waiting for has
indeed occurred.
Generally this is poor practice - it's safer to loop
over the schedule() call until the condition you're
sleeping on has been tested.
You really shouldn't be sleeping in this way on tq_scheduler
if there's any way in which the sleep can take an extended
period of time. You may end up putting important kernel
tasks to sleep.
Best to use schedule_task(), or an independent kernel thread.
-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
