linux-kernel - Re: 2.6.35-rc3: System unresponsive under load

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]

Message-ID: <AANLkTikSh0FZYPppDcF2YDoyDBkIZcAdTBj7iN_9Cta4@mail.gmail.com>
Date:	Sat, 26 Jun 2010 18:47:09 +0200
From:	Luca Tettamanti <kronos.it@...il.com>
To:	Manfred Spraul <manfred@...orfullife.com>
Cc:	Christoph Lameter <cl@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, Julia Lawall <julia@...u.dk>,
	Andrew Morton <akpm@...ux-foundation.org>,
	maciej.rutecki@...il.com
Subject: Re: 2.6.35-rc3: System unresponsive under load

On Sat, Jun 26, 2010 at 5:47 PM, Manfred Spraul
<manfred@...orfullife.com> wrote:
> Hi Luca,
>
> On 06/26/2010 02:52 PM, Luca Tettamanti wrote:
>>
>> They don't seem really hung as before, I see two different behaviours:
>> * Near the end of the run ab is frozen for a few seconds, but in the
>> end all requests are processed; however I see a few "length" errors,
>> meaning that the received page does not match the expected content
>> (I'm testing a static page):
>>
>>
>
> That's consistent with what I see:
> If I run:
> #./semtimedop 100 100&
> #./semtimedop 100 100&
> #./semtimedop 100 100&
> #./semtimedop 100 100&
>
> (i.e.: 4 times the attached test app concurrently), then the system
> sometimes locks up for 10..20 seconds:
> The keyboard is unresponsive, not even the numlock key is processed (i.e.:
> the LED does not change anymore).
> After 10 or 20 seconds, the keyboard reacts again (both to <enter> and to
> Num Lock)
> The stock Fedora 13 kernel (2.6.33.5) does not exhibit this behavior
> The load average is 300 or so, that's expected.

Confirmed here: your test program freezes the system for a while under
2.6.35-rc3, while vanilla 2.6.34 copes fine.
sysrq-t was responsive during the freeze, so I took a snapshot during
it, file is attached.

> I have no idea why and how to debug the behavior.
> # CONFIG_PREEMPT_NONE is not set
> CONFIG_PREEMPT_VOLUNTARY=y
> # CONFIG_PREEMPT is not set

My kernel has PREEMPT enabled.

Luca

Download attachment "dmesg.txt.gz" of type "application/x-gzip" (14565 bytes)