]> git.ipfire.org Git - people/arne_f/kernel.git/commit
staging: lustre: ldlm: pl_recalc time handling is wrong
authorArnd Bergmann <arnd@arndb.de>
Thu, 10 Nov 2016 15:21:20 +0000 (16:21 +0100)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Mon, 9 Jan 2017 07:32:18 +0000 (08:32 +0100)
commit3b2f287b7795aa08cab1c61d99a4a615b63076a7
treed43c956cb1816354b291898bd6b8997689be448e
parent38b2dc0b0f380984cd4fcc208497f8366f85f856
staging: lustre: ldlm: pl_recalc time handling is wrong

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 <jsimmons@infradead.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: James Simmons <jsimmons@infradead.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drivers/staging/lustre/lustre/ldlm/ldlm_pool.c