linux-kernel - [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-next>] [day] [month] [year] [list]

Message-ID: <4969D0D7.2060401@xyzw.org>
Date:	Sun, 11 Jan 2009 02:58:31 -0800
From:	Brian Rogers <brian@...w.org>
To:	linux-kernel@...r.kernel.org
CC:	Ingo Molnar <mingo@...e.hu>
Subject: [BUG] How to get real-time priority using idle priority

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.

Background:

I wrote this program because BOINC is freezing my system occasionally 
when it starts a new task. And it almost always freezes everything 
during boot-up when BOINC starts or when I resume processing after 
having suspended it.

Previously on 2.6.27, I had noticed general sluggishness and frequent 
short pauses of the entire system that were linked to BOINC running. It 
was hard to create a solid testcase for this, though. I wonder if the 
current problem and the previous problem are related...

View attachment "forkdie.c" of type "text/x-csrc" (725 bytes)

View attachment "config-2.6.29-rc1" of type "text/plain" (88821 bytes)