linux-kernel - Re: SCHED

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:	Fri, 18 Jan 2008 08:16:48 -0500
From:	Gregory Haskins <gregory.haskins.ml@...il.com>
To:	linux@...dmangroup.com
CC:	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
	rostedt@...dmis.org
Subject: Re: SCHED_FIFO & system()

linux@...dmangroup.com wrote:
> Hello,
> I have some strange behavior in one of my systems.
> 
> I have a real-time kernel thread under SCHED_FIFO which is running every
> 10ms.
> It is blocking on a semaphore and released by a timer interrupt every 10ms.
> Generally this works really well.
> 
> However, there is a module in the system that makes a / system() / call
> from c-code in user-space;
> 
>   system("run_my_script");
> 
> By calling and running a bash script. Independent of how the actual
> script looks like the real time kernel thread does not get scheduled under
> the time of 80ms -- the time it takes for the system() call to finish.
> 
> I can see when running a LTT session that the wake_up event occurs for
> the real time thread 10ms into the system call but nevertheless the real
> time kernel thread does not get scheduled.
> 
> The thread that calls system("run_my_script") is configured as SCHED_OTHER.
> 
> The Kernel is 2.6.21.
> 
> 
> Anybody who recognize this or similar situations?

Hi,
   I am not sure if this is whats happening to you (*), but there is a 
known problem in the mainline tree related to the system allowing lower 
priority threads to stay on the CPU under certain circumstances.

You can see the problem happening with the following test:

http://rt.wiki.kernel.org/index.php/Preemption_Test

and I know the problem goes back to at least 2.6.16.

Steven Rostedt and I submitted some patches to address the issue, and 
they have been accepted into Ingo's sched-devel tree.  I would suggest 
trying your code against Ingo's tree and see if the problem persists. 
You can get it from:

git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-sched-devel.git

In the event that this does fix your issue, I will defer to Ingo for 
if/when he plans to push these upstream.

(*) I have no information on whether the futex-plist implemetation was 
pulled from the tree to cause your regression.  It is possible that the 
changes between 22 and 23 are just tickling your environment enough to 
bring out this RT-preempt issue.

HTH!

Regards,
-Greg
--
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/