From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759482AbcHYP2L (ORCPT ); Thu, 25 Aug 2016 11:28:11 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:34703 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933835AbcHYP2J (ORCPT ); Thu, 25 Aug 2016 11:28:09 -0400 Date: Thu, 25 Aug 2016 17:25:53 +0200 (CEST) From: Thomas Gleixner To: Nicolai Stange cc: John Stultz , linux-kernel@vger.kernel.org Subject: Re: [RFC v4 22/22] timekeeping: inform clockevents about freq adjustments In-Reply-To: <20160822233320.4548-23-nicstange@gmail.com> Message-ID: References: <20160822233320.4548-1-nicstange@gmail.com> <20160822233320.4548-23-nicstange@gmail.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 23 Aug 2016, Nicolai Stange wrote: > + raw_spin_lock_irqsave(&clockevents_lock, flags); > + list_for_each_entry(dev, &clockevent_devices, list) { > + if (!(dev->features & CLOCK_EVT_FEAT_ONESHOT)) > + continue; > + > + mult_raw = dev->mult; > + if (mult_raw != last_mult_raw) { > + last_mult_raw = mult_raw; > + last_mult_adjusted = > + __clockevents_calc_adjust_freq(mult_raw, > + mult_cs_mono, > + mult_cs_raw); What makes sure that the resulting shift/mult pair is still valid after this adjustment? The non adjusted mult/shift pair might be right at the border of potential overflows and the adjustment might just put it over the edge.... We need at least sanity checks here. Thanks, tglx