linux-kernel - Re: A bug (probably) in stop_all

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <o44nc4dd8tpl94vf9bv81oklq8lt29112t@4ax.com>
Date:	Sat, 13 Sep 2008 20:07:04 +1000
From:	Grant Coady <grant_lkml@...o.com.au>
To:	"karthikeyan S" <karthispeaks@...il.com>
Cc:	linux-kernel@...r.kernel.org, Willy Tarreau <w@....eu>
Subject: Re: A bug (probably) in stop_all_threads

On Sat, 13 Sep 2008 13:57:28 +0530, "karthikeyan S" <karthispeaks@...il.com> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/