linux-kernel - Re: [PATCH 6/7] Cpuidle: Deal with timer expiring in the past

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: <4412976.XQe5SncyQX@vostro.rjw.lan>
Date:	Tue, 25 Feb 2014 01:20:28 +0100
From:	"Rafael J. Wysocki" <rjw@...ysocki.net>
To:	Nicolas Pitre <nicolas.pitre@...aro.org>,
	Tuukka Tikkanen <tuukka.tikkanen@...aro.org>
Cc:	linux-pm@...r.kernel.org, daniel.lezcano@...aro.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 6/7] Cpuidle: Deal with timer expiring in the past

On Monday, February 24, 2014 12:05:39 PM Nicolas Pitre wrote:
> On Mon, 24 Feb 2014, Tuukka Tikkanen wrote:
> 
> > Sometimes (fairly often) when the cpuidle menu governor is making a decision
> > about idle state to enter the next timer for the cpu appears to expire in
> > the past. The menu governor expects the expiry to always be in the future
> > and in fact stores the time delta in an unsigned variable. However, when
> > the expiry is in the past, the value returned by tick_nohz_get_sleep_length
> > can be negative. This patch prevents using negative values, instead making
> > the governor return immediately similar to having latency requirement set
> > to 0.
> > 
> > Note: As with latency == 0, the return value is 0 with no check to see if
> > the state 0 has been disabled or not.
> 
> In your cover letter you mention some occurrences of the negative result 
> being observed on x86.  That information is worth capturing in the 
> commit log as well to distinguish between theoretical problems from 
> actual observations.

In my opinion that applies to the other patches in the series too.  In all
cases it would be good to know whether or not the problems addressed are
theoretical or they can be reproduced in practice (and if so, then how), or
they already have been reported by somebody.

In the two latter cases the patches would be good candidates for -stable,
in particular.

Thanks,
Rafael

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