From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751642AbbIMIc4 (ORCPT ); Sun, 13 Sep 2015 04:32:56 -0400 Received: from mail-wi0-f173.google.com ([209.85.212.173]:36982 "EHLO mail-wi0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751157AbbIMIct (ORCPT ); Sun, 13 Sep 2015 04:32:49 -0400 Date: Sun, 13 Sep 2015 10:32:44 +0200 From: Ingo Molnar To: John Stultz , Linus Torvalds , Andrew Morton , Peter Zijlstra , Thomas Gleixner Cc: LKML , Nuno =?iso-8859-1?Q?Gon=E7alves?= , Miroslav Lichvar , Prarit Bhargava , Richard Cochran , Thomas Gleixner , stable@vger.kernel.org Subject: Re: [PATCH 1/2] time: Fix timekeeping_freqadjust()'s incorrect use of abs() instead of abs64() Message-ID: <20150913083244.GA29934@gmail.com> References: <1441840051-20244-1-git-send-email-john.stultz@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1441840051-20244-1-git-send-email-john.stultz@linaro.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * John Stultz wrote: > The internal clocksteering done for fine-grained error correction > uses a logarithmic approximation, so any time adjtimex() adjusts > the clock steering, timekeeping_freqadjust() quickly approximates > the correct clock frequency over a series of ticks. > > Unfortunately, the logic in timekeeping_freqadjust(), introduced > in commit dc491596f639438 (Rework frequency adjustments to work > better w/ nohz), used the abs() function with a s64 error value > to calculate the size of the approximated adjustment to be made. > > Per include/linux/kernel.h: "abs() should not be used for 64-bit > types (s64, u64, long long) - use abs64()". > > Thus on 32-bit platforms, this resulted in the clocksteering to > take a quite dampended random walk trying to converge on the > proper frequency, which caused the adjustments to be made much > slower then intended (most easily observed when large adjustments > are made). > > This patch fixes the issue by using abs64() instead. > /* Sort out the magnitude of the correction */ > - tick_error = abs(tick_error); > + tick_error = abs64(tick_error); Ugh, and we had this bug for almost two years! Would it be possible to make abs() warn about 64-bit types during build time, to prevent such mishaps? Thanks, Ingo