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]

Date:	Tue, 16 Sep 2008 11:19:58 +0530
From:	"karthikeyan S" <karthispeaks@...il.com>
To:	"Willy Tarreau" <w@....eu>
Cc:	"Grant Coady" <gcoady.lk@...il.com>, linux-kernel@...r.kernel.org
Subject: Re: A bug (probably) in stop_all_threads

Hi Willy,

Thanks for getting back. Yes, I tried to set the state to
TASK_INTERRUPTIBLE. It solves the issue. The other processes now get a
chance to handle the SIGSTOP sent to them.

-karthik

On Tue, Sep 16, 2008 at 10:47 AM, Willy Tarreau <w@....eu> wrote:
> Hi karthik,
>
> Just a quick note to tell you that I have not missed your mail, I
> just need some time to analyse your report and the code related
> to it. Have you tried setting TASK_INTERRUPTIBLE as you suggest ?
> At first sight, it seems to make sense.
>
> Regards,
> Willy
>
> On Sat, Sep 13, 2008 at 08:07:04PM +1000, Grant Coady wrote:
>> 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/