Re: A bug (probably) in stop_all_threads

[Grant Coady]

On Sat, 13 Sep 2008 13:57:28 +0530, "karthikeyan S" <karthispeaks@xxxxxxxxx> wrote:

CC added.

>Hi,
>
>Apologies if I am posting this message in an incorrect mailing list
>and for bringing up an issue with older kernel version (2.4), and if
>the issue had been brought up earlier and I missed it.
>
>There seems to be a bug with stop_all_threads function in 2.4. The
>function sends SIGSTOP to all the threads in the thread group and
>waits until all the threads get their state changed accordingly.
>
>While waiting, if it finds that the event has not occurred, it tires
>to yield the processor to other processes by calling
>schedule_timeout().
>
>Bur before calling schedule_timeout() it does not set the task state
>to either TASK_INTERRUPTIBLE or TASK_UNINTERRUPTIBLE.
>So schedule_timeout() does not do anything effectively.
>
>This causes a problem in our device which uses kernel 2.4. When we
>have a sigsegv from the task which runs at highest priority, the
>control is stuck waiting for all the threads in the thread group to
>change their task state. But the other threads never get a chance to
>run and the SIGSTOP sent to them is of no effect.
>
>When  I changed the stop_all_threads function to set the task state to
>TASK_INTERRUPTIBLE, the problem disappears.
>
>So is this a real issue that stop_all_threads() does not set the
>current task to TASK_INTERRUPTIBLE before calling schedule_timeout()?
>
>Please provide your feedback. Thanks a lot.
>
>-karthik

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/