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 07:17:51 +0200
From:	Willy Tarreau <w@....eu>
To:	karthikeyan S <karthispeaks@...il.com>
Cc:	Grant Coady <gcoady.lk@...il.com>, linux-kernel@...r.kernel.org
Subject: Re: A bug (probably) in stop_all_threads

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ