lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sat, 9 May 2020 20:48:42 +0200
From:   Christophe Leroy <christophe.leroy@...roup.eu>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Nathan Lynch <nathanl@...ux.ibm.com>,
        linux-arch <linux-arch@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Paul Mackerras <paulus@...ba.org>,
        Andy Lutomirski <luto@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Vincenzo Frascino <vincenzo.frascino@....com>,
        linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>
Subject: Re: [PATCH v8 8/8] powerpc/vdso: Provide __kernel_clock_gettime64()
 on vdso32



Le 09/05/2020 à 17:54, Christophe Leroy a écrit :
> 
> 
> Le 28/04/2020 à 18:05, Arnd Bergmann a écrit :
>> On Tue, Apr 28, 2020 at 3:16 PM Christophe Leroy
>> <christophe.leroy@....fr> wrote:
>>>
>>> Provides __kernel_clock_gettime64() on vdso32. This is the
>>> 64 bits version of __kernel_clock_gettime() which is
>>> y2038 compliant.
>>>
>>> Signed-off-by: Christophe Leroy <christophe.leroy@....fr>
>>
>> Looks good to me
>>
>> Reviewed-by: Arnd Bergmann <arnd@...db.de>
>>
>> There was a bug on ARM for the corresponding function, so far it is 
>> unclear
>> if this was a problem related to particular hardware, the 32-bit 
>> kernel code,
>> or the common implementation of clock_gettime64 in the vdso library,
>> see https://github.com/richfelker/musl-cross-make/issues/96
>>
>> Just to be sure that powerpc is not affected by the same issue, can you
>> confirm that repeatedly calling clock_gettime64 on powerpc32, alternating
>> between vdso and syscall, results in monotically increasing times?
>>
> 
> I think that's one of the things vdsotest checks, so yes that's ok I think.
> 

Here is the full result with vdsotest:

gettimeofday: syscall: 3715 nsec/call
gettimeofday:    libc: 794 nsec/call
gettimeofday:    vdso: 947 nsec/call
getcpu: syscall: 1614 nsec/call
getcpu:    libc: 484 nsec/call
getcpu:    vdso: 184 nsec/call
clock-gettime64-realtime-coarse: syscall: 3152 nsec/call
clock-gettime64-realtime-coarse:    libc: not tested
clock-gettime64-realtime-coarse:    vdso: 653 nsec/call
clock-getres-realtime-coarse: syscall: 2963 nsec/call
clock-getres-realtime-coarse:    libc: 745 nsec/call
clock-getres-realtime-coarse:    vdso: 553 nsec/call
clock-gettime-realtime-coarse: syscall: 5120 nsec/call
clock-gettime-realtime-coarse:    libc: 731 nsec/call
clock-gettime-realtime-coarse:    vdso: 577 nsec/call
clock-gettime64-realtime: syscall: 3719 nsec/call
clock-gettime64-realtime:    libc: not tested
clock-gettime64-realtime:    vdso: 976 nsec/call
clock-getres-realtime: syscall: 2496 nsec/call
clock-getres-realtime:    libc: 745 nsec/call
clock-getres-realtime:    vdso: 546 nsec/call
clock-gettime-realtime: syscall: 4800 nsec/call
clock-gettime-realtime:    libc: 1080 nsec/call
clock-gettime-realtime:    vdso: 1798 nsec/call
clock-gettime64-boottime: syscall: 4132 nsec/call
clock-gettime64-boottime:    libc: not tested
clock-gettime64-boottime:    vdso: 975 nsec/call
clock-getres-boottime: syscall: 2497 nsec/call
clock-getres-boottime:    libc: 730 nsec/call
clock-getres-boottime:    vdso: 546 nsec/call
clock-gettime-boottime: syscall: 3728 nsec/call
clock-gettime-boottime:    libc: 1079 nsec/call
clock-gettime-boottime:    vdso: 941 nsec/call
clock-gettime64-tai: syscall: 4148 nsec/call
clock-gettime64-tai:    libc: not tested
clock-gettime64-tai:    vdso: 955 nsec/call
clock-getres-tai: syscall: 2494 nsec/call
clock-getres-tai:    libc: 730 nsec/call
clock-getres-tai:    vdso: 545 nsec/call
clock-gettime-tai: syscall: 3729 nsec/call
clock-gettime-tai:    libc: 1079 nsec/call
clock-gettime-tai:    vdso: 927 nsec/call
clock-gettime64-monotonic-raw: syscall: 3677 nsec/call
clock-gettime64-monotonic-raw:    libc: not tested
clock-gettime64-monotonic-raw:    vdso: 1032 nsec/call
clock-getres-monotonic-raw: syscall: 2494 nsec/call
clock-getres-monotonic-raw:    libc: 745 nsec/call
clock-getres-monotonic-raw:    vdso: 545 nsec/call
clock-gettime-monotonic-raw: syscall: 3276 nsec/call
clock-gettime-monotonic-raw:    libc: 1140 nsec/call
clock-gettime-monotonic-raw:    vdso: 1002 nsec/call
clock-gettime64-monotonic-coarse: syscall: 4099 nsec/call
clock-gettime64-monotonic-coarse:    libc: not tested
clock-gettime64-monotonic-coarse:    vdso: 653 nsec/call
clock-getres-monotonic-coarse: syscall: 2962 nsec/call
clock-getres-monotonic-coarse:    libc: 745 nsec/call
clock-getres-monotonic-coarse:    vdso: 545 nsec/call
clock-gettime-monotonic-coarse: syscall: 4297 nsec/call
clock-gettime-monotonic-coarse:    libc: 730 nsec/call
clock-gettime-monotonic-coarse:    vdso: 592 nsec/call
clock-gettime64-monotonic: syscall: 3863 nsec/call
clock-gettime64-monotonic:    libc: not tested
clock-gettime64-monotonic:    vdso: 975 nsec/call
clock-getres-monotonic: syscall: 2494 nsec/call
clock-getres-monotonic:    libc: 745 nsec/call
clock-getres-monotonic:    vdso: 545 nsec/call
clock-gettime-monotonic: syscall: 3465 nsec/call
clock-gettime-monotonic:    libc: 1079 nsec/call
clock-gettime-monotonic:    vdso: 927 nsec/call

Christophe

Powered by blists - more mailing lists