From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linuxfoundation.org ([140.211.169.12]:35982 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752531AbdAFOaN (ORCPT ); Fri, 6 Jan 2017 09:30:13 -0500 Subject: Patch "staging: lustre: ldlm: pl_recalc time handling is wrong" has been added to the 4.9-stable tree To: arnd@arndb.de, gregkh@linuxfoundation.org, jsimmons@infradead.org Cc: , From: Date: Fri, 06 Jan 2017 15:28:19 +0100 Message-ID: <1483712899234174@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ANSI_X3.4-1968 Content-Transfer-Encoding: 8bit Sender: stable-owner@vger.kernel.org List-ID: This is a note to let you know that I've just added the patch titled staging: lustre: ldlm: pl_recalc time handling is wrong to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: staging-lustre-ldlm-pl_recalc-time-handling-is-wrong.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let know about it. >>From b8cb86fd95bb461c3496e1f4b4083b198c963a9c Mon Sep 17 00:00:00 2001 From: Arnd Bergmann Date: Thu, 10 Nov 2016 16:21:20 +0100 Subject: staging: lustre: ldlm: pl_recalc time handling is wrong From: Arnd Bergmann commit b8cb86fd95bb461c3496e1f4b4083b198c963a9c upstream. 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. Fixes: 8f83409cf238 ("staging/lustre: use 64-bit time for pl_recalc") Reported-by: James Simmons Signed-off-by: Arnd Bergmann Reviewed-by: James Simmons Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman --- drivers/staging/lustre/lustre/ldlm/ldlm_pool.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) --- 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_ 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_ 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, 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); Patches currently in stable-queue which might be from arnd@arndb.de are queue-4.9/staging-lustre-ldlm-pl_recalc-time-handling-is-wrong.patch queue-4.9/arm64-tegra-add-vdd_gpu-regulator-to-jetson-tx1.patch