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 for Android: free password hash cracker in your pocket
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Fri,  3 Apr 2015 09:04:03 +0530
From:	Viresh Kumar <viresh.kumar@...aro.org>
To:	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>
Cc:	linaro-kernel@...ts.linaro.org, linux-kernel@...r.kernel.org,
	Frederic Weisbecker <fweisbec@...il.com>,
	Kevin Hilman <khilman@...aro.org>,
	Daniel Lezcano <daniel.lezcano@...aro.org>,
	Preeti U Murthy <preeti@...ux.vnet.ibm.com>,
	Viresh Kumar <viresh.kumar@...aro.org>
Subject: [PATCH V2 0/2] clockevents: Stop unused clockevent devices

Hi,

A clockevent device is used to service timers/hrtimers requests and the next
event (when it should fire) is decided by the timer/hrtimer expiring next. When
no timers/hrtimers are pending to be serviced, the expiry time is set to a
special value: KTIME_MAX.

This would normally happen with NO_HZ_{IDLE|FULL} in both LOWRES/HIGHRES modes.

When 'expiry == KTIME_MAX', we either cancel the 'tick-sched' hrtimer
(NOHZ_MODE_HIGHRES) or skip reprogramming clockevent device (NOHZ_MODE_LOWRES).
But, the clockevent device is already reprogrammed from the tick-handler for
next tick.

As the clock event device is programmed in ONESHOT mode it will at least fire
one more time (unnecessarily). Timers on few implementations (like
arm_arch_timer, etc.) only support PERIODIC mode and their drivers emulate
ONESHOT over that. Which means that on these platforms we will get spurious
interrupts periodically (at last programmed interval rate, normally tick rate).

In order to avoid spurious interrupts, the unused clockevent device should be
stopped or its interrupts should be masked.

Thomas suggested to add an optional state ONESHOT_STOPPED to solve this problem:
lkml.org/lkml/2014/5/9/508.

First patch implements the required infrastructure to start/stop clockevent
device. The second patch stops/starts clockevent devices as and when required.

It is also pushed here:

git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/linux.git tick/oneshot-stopped

@Preeti: I have applied your Reviewed-by only for the first commit as others
have changed significantly. Feel free to give it again :)

V1->V2:
- Peter & Ingo suggested to to start/stop clockevent device from
  tick_program_event() instead of the call sites that called
  tick_program_event().

--
viresh

Viresh Kumar (2):
  clockevents: Introduce CLOCK_EVT_STATE_ONESHOT_STOPPED state
  Clockevents: Stop unused clockevent devices

 include/linux/clockchips.h |  7 ++++++-
 kernel/time/clockevents.c  | 18 +++++++++++++++++-
 kernel/time/hrtimer.c      |  6 ++----
 kernel/time/tick-oneshot.c | 16 ++++++++++++++++
 kernel/time/timer_list.c   |  6 ++++++
 5 files changed, 47 insertions(+), 6 deletions(-)

-- 
2.3.0.rc0.44.ga94655d

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ