Hi Arnd, On 5/5/20 3:50 PM, Arnd Bergmann wrote: > On Wed, Apr 29, 2020 at 1:34 PM Vincenzo Frascino > <vincenzo.frascino@xxxxxxx> wrote: >> >> This series extends the kselftests for the vDSO library making sure: that >> they compile correctly on non x86 platforms, that they can be cross >> compiled and introducing new tests that verify the correctness of the >> library. >> >> The so extended vDSO kselftests have been verified on all the platforms >> supported by the unified vDSO library [1]. >> >> The only new patch that this series introduces is the first one, patch 2 and >> patch 3 have already been reviewed in past as part of other series [2] [3]. >> >> [1] https://lore.kernel.org/lkml/20190621095252.32307-1-vincenzo.frascino@xxxxxxx >> [2] https://lore.kernel.org/lkml/20190621095252.32307-26-vincenzo.frascino@xxxxxxx >> [3] https://lore.kernel.org/lkml/20190523112116.19233-4-vincenzo.frascino@xxxxxxx > > Hi Vincenzo, > > Not sure if you are aware of the recent bug report about clock_gettime64() > returning invalid times on some arm32 kernels: > https://github.com/raspberrypi/linux/issues/3579 > No, I was not aware of the problem. There has been no mention on the arm list (unless I missed it). I can try to have a look at it as soon as I get some time. > Regardless of when that gets fixed or by whom, I wonder if kselftest should > also check for consistency, i.e. call both the vdso and the syscall version of > clock_gettime() and clock_gettime64() and check that the results are always > in sequence. > The test #4 partially does that: it calls syscall-vdso-syscall and verifies that the sequencing is correct. I reused the x86 code for that. I could extend it to clock_gettime64() and make sure it builds on all the platforms. > Arnd > -- Regards, Vincenzo
