linux-kernel - Re: [PATCH 2/8] posix-cpu-timers: fix acounting delta

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: <20130603190730.GA31107@somewhere>
Date:	Mon, 3 Jun 2013 21:07:32 +0200
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	kosaki.motohiro@...il.com
Cc:	linux-kernel@...r.kernel.org,
	Olivier Langlois <olivier@...llion01.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
Subject: Re: [PATCH 2/8] posix-cpu-timers: fix acounting delta_exec twice

On Sun, May 26, 2013 at 05:35:42PM -0400, kosaki.motohiro@...il.com wrote:
> From: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
> 
> Currently glibc rt/tst-cpuclock2 test(*) sporadically fails because
> scheduler delta can be accounted twice from thread_group_cputimer()
> and account_group_exec_runtime().
> 
> Finally, clock_nanosleep() wakes up earlier than an argument. This is posix
> violation. This issue was introduced by commit d670ec1317 (posix-cpu-timers:
> Cure SMP wobbles).
> 
> (*) http://sourceware.org/git/?p=glibc.git;a=blob;f=rt/tst-cpuclock2.c;h=6752721717f959e89c0d692b3f1ee082d507eec2;hb=HEAD
> 
> Cc: Olivier Langlois <olivier@...llion01.com>
> Cc: Thomas Gleixner <tglx@...utronix.de>

So with this patch the timer sample can be (nr_threads * TICK_NSEC) nsecs behind the
clock in the worst case.

This is still better than possibly (nr_threads * TICK_NSEC) nsecs ahead of the clock in
the worst case like we have before the patch :)

But the worst case can be unbounded with full dynticks tasks. May be the ideal thing
would be to perform an update_curr() on the threads before we read their sum_exec_runtime,
This way we make sure we are never far away behind.

This needs to be done on top of your change anyway because we still want to avoid
the double count, so: Acked-by: Frederic Weisbecker <fweisbec@...il.com>

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