From patchwork Thu Nov 10 15:21:20 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Arnd Bergmann X-Patchwork-Id: 101541 Delivered-To: patch@linaro.org Received: by 10.140.97.165 with SMTP id m34csp782137qge; Thu, 10 Nov 2016 07:23:54 -0800 (PST) X-Received: by 10.98.24.136 with SMTP id 130mr11080742pfy.73.1478791434164; Thu, 10 Nov 2016 07:23:54 -0800 (PST) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n22si5391989pfi.246.2016.11.10.07.23.53; Thu, 10 Nov 2016 07:23:54 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934163AbcKJPXu (ORCPT + 27 others); Thu, 10 Nov 2016 10:23:50 -0500 Received: from mout.kundenserver.de ([212.227.126.131]:59595 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933482AbcKJPXt (ORCPT ); Thu, 10 Nov 2016 10:23:49 -0500 Received: from wuerfel.localnet ([78.43.20.153]) by mrelayeu.kundenserver.de (mreue004 [212.227.15.129]) with ESMTPSA (Nemesis) id 0Ls5Pv-1colD80uP1-013rRV; Thu, 10 Nov 2016 16:21:25 +0100 From: Arnd Bergmann To: Greg Kroah-Hartman Cc: "Dilger, Andreas" , James Simmons , "devel@driverdev.osuosl.org" , "Drokin, Oleg" , Linux Kernel Mailing List , Lustre Development List Subject: [PATCH v2] staging: lustre: ldlm: pl_recalc time handling is wrong Date: Thu, 10 Nov 2016 16:21:20 +0100 Message-ID: <4839295.T6k2aHkh3K@wuerfel> User-Agent: KMail/5.1.3 (Linux/4.4.0-34-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <20161110122108.GA7580@kroah.com> References: <1478573240-12850-1-git-send-email-jsimmons@infradead.org> <1594836.LAbS3nYoXQ@wuerfel> <20161110122108.GA7580@kroah.com> MIME-Version: 1.0 X-Provags-ID: V03:K0:QTMu/yr8ITcXvGFhU70T8oQmcr3SwWyHTKN5DTqZUG3tLEMjcLZ 9PBmnPkRqfVxghPu/ObchdbS2J02mBgeRg3x4dOeDJIG4D+r2QAHmgIIfAtvK7lfDFLxYwh Bg6t5PtPmGv/sggtosizfTdNMJZPOLkcbM67Hks2YxCprtwjw+39w1kroJAzgogD0xTbsVz RnuFLnyF501j2eaVcUfQA== X-UI-Out-Filterresults: notjunk:1; V01:K0:iPB41VWCXwg=:fbXywATcAap/K/j3fkugg/ 3zQJDjpZ4MbGWWa11obKIk3jhmm0plEGC2I71qP39KPgVIK/aNyaXzYtMyggR3nyFuHwxDfwU HbOF5SiF9rF+/NHtOuo0BJ+JNvQo/S4sj9wrXx311QdzAcNqf8AMIT3cJU/dyryeOoI5wm45j Av2vUp9o7EV9WKMWHQ+/u0qdMuDueM5XjrWUtx/KqRlWP7LECHimmW0wyelxeIt7VTzmk+Q2q /IVrwdii8/BUF/XcUJ06O0bnQWXv3u7ieTEBcPj4B3yzHc4SBxNnPNeKGSsIoSd3Sx+clUDLf uJX36GvILCxOJDbbU07QFS0dYWAkOJsBrl7hNUQThIBb63fef1caCKID3csUxYhy9EM9uHPjI cfJcNuoClgqAwfTMwo7SDE7sepulXJ8OooKdJAM6IY9+gedhvNHRRdYyDCIiXnI3L/FRY9kfU VdDuc6R0DtMs471KtOHCVsSf/BSx1rLKfTzlf4/FbYT/BAK+sbxwNfU7H1kB54fFfRUmz1cBD REFFEmE4S2b3uliDt2W5x99GAMfixK79CRCaygptaTfBacpVzqZuVW/ydrzrsfyyylmzf+bKD lzVQLVYueo9LnG9oWQ/yORCs083LnOqG08DH4AybWuZ40W0IO9cdhIWL1hGgxoKeQ7p0eSU3c gNyP3OdMATWWRcyOo8k09ekwobhLw1Zxr9L7mdMjYkiSjmub+WdKPM9xwRfatevwMFzHdGppK zSelJ9bfxVHNca/J Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org James Simmons reports: > The ldlm_pool field pl_recalc_time is set to the current > monotonic clock value but the interval period is calculated > with the wall clock. This means the interval period will > always be far larger than the pl_recalc_period, which is > just a small interval time period. The correct thing to > do is to use monotomic clock current value instead of the > wall clocks value when calculating recalc_interval_sec. This broke when I converted the 32-bit get_seconds() into ktime_get_{real_,}seconds() inconsistently. Either one of those two would have worked, but mixing them does not. Staying with the original intention of the patch, this changes the ktime_get_seconds() calls into ktime_get_real_seconds(), using real time instead of mononic time. Cc: stable@vger.kernel.org # v4.4+ Fixes: 8f83409cf238 ("staging/lustre: use 64-bit time for pl_recalc") Reported-by: James Simmons Signed-off-by: Arnd Bergmann --- v2: James' patch was similarly incomplete to mine, as it only addressed some of the calls. With this new version, all ktime accessors use the same time domain. diff --git a/drivers/staging/lustre/lustre/ldlm/ldlm_pool.c b/drivers/staging/lustre/lustre/ldlm/ldlm_pool.c index 19831c555c49..b820309d70e3 100644 --- a/drivers/staging/lustre/lustre/ldlm/ldlm_pool.c +++ b/drivers/staging/lustre/lustre/ldlm/ldlm_pool.c @@ -356,10 +356,10 @@ static int ldlm_pool_recalc(struct ldlm_pool *pl) u32 recalc_interval_sec; int count; - recalc_interval_sec = ktime_get_seconds() - pl->pl_recalc_time; + recalc_interval_sec = ktime_get_real_seconds() - pl->pl_recalc_time; if (recalc_interval_sec > 0) { spin_lock(&pl->pl_lock); - recalc_interval_sec = ktime_get_seconds() - pl->pl_recalc_time; + recalc_interval_sec = ktime_get_real_seconds() - pl->pl_recalc_time; if (recalc_interval_sec > 0) { /* @@ -382,7 +382,7 @@ static int ldlm_pool_recalc(struct ldlm_pool *pl) count); } - recalc_interval_sec = pl->pl_recalc_time - ktime_get_seconds() + + recalc_interval_sec = pl->pl_recalc_time - ktime_get_real_seconds() + pl->pl_recalc_period; if (recalc_interval_sec <= 0) { /* DEBUG: should be re-removed after LU-4536 is fixed */ @@ -657,7 +657,7 @@ int ldlm_pool_init(struct ldlm_pool *pl, struct ldlm_namespace *ns, spin_lock_init(&pl->pl_lock); atomic_set(&pl->pl_granted, 0); - pl->pl_recalc_time = ktime_get_seconds(); + pl->pl_recalc_time = ktime_get_real_seconds(); atomic_set(&pl->pl_lock_volume_factor, 1); atomic_set(&pl->pl_grant_rate, 0);