linux-kernel - Re: 2.6.39-rc4+: Kernel leaking memory during FS scanning, regression?

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: <alpine.LFD.2.02.1104282251080.3005@ionos>
Date:	Thu, 28 Apr 2011 23:04:01 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Bruno Prémont <bonbons@...ux-vserver.org>
cc:	sedat.dilek@...il.com, Mike Galbraith <efault@....de>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Mike Frysinger <vapier.adi@...il.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	LKML <linux-kernel@...r.kernel.org>, linux-mm@...ck.org,
	linux-fsdevel@...r.kernel.org,
	"Paul E. McKenney" <paul.mckenney@...aro.org>,
	Pekka Enberg <penberg@...nel.org>,
	John Stultz <johnstul@...ibm.com>
Subject: Re: 2.6.39-rc4+: Kernel leaking memory during FS scanning,
 regression?

On Thu, 28 Apr 2011, Bruno Prémont wrote:
> Timer List Version: v0.6
> HRTIMER_MAX_CLOCK_BASES: 3
> now at 1150126155286 nsecs
> 
> cpu: 0
>  clock 0:
>   .base:       c1559360
>   .index:      0
>   .resolution: 1 nsecs
>   .get_time:   ktime_get_real
>   .offset:     1304021489280954699 nsecs
> active timers:
>  #0: def_rt_bandwidth, sched_rt_period_timer, S:01, enqueue_task_rt, swapper/1
>  # expires at 1304028703000000000-1304028703000000000 nsecs [in 1304027552873844714 to 1304027552873844714 nsecs]

Ok, that expiry time is obviously bogus as it does not account the offset:

So in reality it's: expires in: 6063592890015ns 

Which is still completely wrong. The timer should expire at max a
second from now. But it's going to expire in 6063.592890015 seconds
from now, which is pretty much explaining the after 2hrs stuff got
going again.

But the real interesting question is why he heck is that timer on
CLOCK_REALTIME ???? It is initalized for CLOCK_MONOTONIC.

/me suspects hrtimer changes to be the real culprit.

John ????

Thanks,

	tglx