linux-kernel - Re: [BUG] How to get real-time priority using idle priority

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:	Mon, 12 Jan 2009 06:09:01 +0100
From:	Mike Galbraith <efault@....de>
To:	Brian Rogers <brian@...w.org>
Cc:	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>
Subject: Re: [BUG] How to get real-time priority using idle priority

On Sun, 2009-01-11 at 02:58 -0800, Brian Rogers wrote:
> The attached program gives itself idle priority, then forks off two 
> child processes that execute a busy loop. The result is that sometimes 
> all other processes stop and the whole system freezes until this program 
> exits. An affected system will respond to pings, but X freezes, the 
> cursor won't move, SSH sessions won't respond or echo characters back, 
> and not even a text console will budge. Hitting Alt-SysRq-N twice can 
> sometimes unfreeze the system, or you can just wait for the program to exit.
> 
> This bug is in 2.6.29-rc1. I have also observed this bug in 2.6.28 on 
> two dual-core systems, an Athlon X2 desktop and a Core 2 Duo laptop. 
> Both are running a 64-bit system. Using i386 and amd64 Ubuntu Jaunty 
> daily builds with a 2.6.28 kernel, I found I could reproduce the problem 
> with the 64-bit kernel, but not the 32-bit kernel. Since that might just 
> be due to a difference in the kernel configurations, I'm attaching the 
> kernel configuration on which I know this problem can be triggered.
> 
> It may take a couple-dozen runs of this program for the freeze to occur. 
> Just hit control-C and re-run the program until it happens. When it does 
> freeze, the effect is immediate, so there's no chance you'll interrupt 
> the program too soon.

Hi,

I haven't been able to reproduce complete hangs, but with your proggy
adapted to my quad, _and_ the addition of a SCHED_NORMAL hog, I can
reproduce some very bad interactivity, including massive character
repeats while attempting to type, and general "lurchiness" (_bad_ wakeup
latency).  I'll poke it with a sharp stick or two.

	-Mike

--
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/