linux-kernel - Re: scheduler bug: process running since 5124095h

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, 29 Mar 2010 21:04:06 +0900
From:	Hidetoshi Seto <seto.hidetoshi@...fujitsu.com>
To:	Mike Galbraith <efault@....de>
CC:	Török Edwin <edwintorok@...il.com>,
	Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <peterz@...radead.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: scheduler bug: process running since 5124095h

(2010/03/29 19:52), Mike Galbraith wrote:
> On Sun, 2010-03-28 at 11:49 +0300, Török Edwin wrote:
>> On 03/27/2010 11:46 AM, Török Edwin wrote:
>>> Hi Ingo, Peter,
>>>
>>> top has just shown me this:
>>> PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>>>
>>>                                                                  6524
>>> edwin     20   0  228m  10m 8116 R    2  0.3  5124095h gkrellm
>>>
>>> Now obviously that process is not running since 5124095h!
>>> It looks like some overflow to me, the time in nanoseconds would be
>>> approx 0xFFFFFE1D2D476000, which is approx. minus 34 minutes.
>>> Thats about consistent with the uptime, but I don't know why it became
>>> negative:
>>>  11:45:48 up 42 min,  9 users,  load average: 0.56, 0.25, 0.19
>>>
>>> I've attached the cfs-debug-info.sh output.
>>>
>>> This happens when using Linux 2.6.33 (actually glisse's drm-radeon tree
>>> which is based on 2.6.33), its the first time I noticed this.
>>>
>>> I don't know what caused it, the last things I did was:
>>
>> I have a simple way to reproduce this:
>> 1. Boot the system, run top, confirm everything is normal
>> 2. Run latencytop, and quit (I used version 0.5)
>> 3. Run top, see 5124095h in the TIME column
> 
> Indeed, and I don't even have CONFIG_LATENCYTOP set.  It bisected to...
> 
> 761b1d26df542fd5eb348837351e4d2f3bc7bffe is the first bad commit
> commit 761b1d26df542fd5eb348837351e4d2f3bc7bffe
> Author: Hidetoshi Seto <seto.hidetoshi@...fujitsu.com>
> Date:   Thu Nov 12 13:33:45 2009 +0900

Wow, it's easy to reproduce. I'll check it later... 


Thanks,
H.Seto

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