On Mon, May 21, 2018 at 06:57:26PM +0100, Fabrizio Castro wrote: > From: John Stultz <john.stultz@xxxxxxxxxx> > > commit 3d88d56c5873f6eebe23e05c3da701960146b801 upstream. > > Due to how the MONOTONIC_RAW accumulation logic was handled, > there is the potential for a 1ns discontinuity when we do > accumulations. This small discontinuity has for the most part > gone un-noticed, but since ARM64 enabled CLOCK_MONOTONIC_RAW > in their vDSO clock_gettime implementation, we've seen failures > with the inconsistency-check test in kselftest. > > This patch addresses the issue by using the same sub-ns > accumulation handling that CLOCK_MONOTONIC uses, which avoids > the issue for in-kernel users. > > Since the ARM64 vDSO implementation has its own clock_gettime > calculation logic, this patch reduces the frequency of errors, > but failures are still seen. The ARM64 vDSO will need to be > updated to include the sub-nanosecond xtime_nsec values in its > calculation for this issue to be completely fixed. > > Signed-off-by: John Stultz <john.stultz@xxxxxxxxxx> > Tested-by: Daniel Mentz <danielmentz@xxxxxxxxxx> > Cc: Prarit Bhargava <prarit@xxxxxxxxxx> > Cc: Kevin Brodsky <kevin.brodsky@xxxxxxx> > Cc: Richard Cochran <richardcochran@xxxxxxxxx> > Cc: Stephen Boyd <stephen.boyd@xxxxxxxxxx> > Cc: Will Deacon <will.deacon@xxxxxxx> > Cc: "stable #4 . 8+" <stable@xxxxxxxxxxxxxxx> > Cc: Miroslav Lichvar <mlichvar@xxxxxxxxxx> > Link: http://lkml.kernel.org/r/1496965462-20003-3-git-send-email-john.stultz@xxxxxxxxxx > Signed-off-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx> > [fabrizio: cherry-pick to 4.4. Kept cycle_t type for function > logarithmic_accumulation local variable "interval". Dropped > casting of "interval" variable] > Signed-off-by: Fabrizio Castro <fabrizio.castro@xxxxxxxxxxxxxx> > Signed-off-by: Biju Das <biju.das@xxxxxxxxxxxxxx> > --- > Hello Greg, > > we noticed tools/testing/selftests/timers/clocksource-switch.c > was failing for us, this patch fixes the cause of the failure. > Are you happy to take this patch? For what kernel tree(s)? And why did you not cc: the developers and maintainer of this subsystem? thanks, greg k-h
