All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vincenzo Frascino <vincenzo.frascino@arm.com>
To: Michael Ellerman <mpe@ellerman.id.au>,
	linux-arch@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	linux-s390@vger.kernel.org, linux-kselftest@vger.kernel.org
Cc: Christophe Leroy <christophe.leroy@c-s.fr>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Paul Mackerras <paulus@samba.org>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	Shuah Khan <shuah@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Arnd Bergmann <arnd@arndb.de>
Subject: Re: [PATCH v4 3/3] kselftest: Extend vDSO selftest to clock_getres
Date: Thu, 13 Jun 2019 16:22:49 +0100	[thread overview]
Message-ID: <5262a024-7af1-4792-ec74-4cb5f2b0e76c@arm.com> (raw)
In-Reply-To: <afb7395f-43e9-c304-2db2-349e6727b687@arm.com>

Hi Michael,

I wanted to check with you if you had time to have a look at my new version (v5)
of the patches with the fixed test, and if they are ready to be merged or if
there is anything else I can do.

Thanks and Regards,
Vincenzo

On 28/05/2019 12:57, Vincenzo Frascino wrote:
> Hi Michael,
> 
> thank you for your reply.
> 
> On 28/05/2019 07:19, Michael Ellerman wrote:
>> Vincenzo Frascino <vincenzo.frascino@arm.com> writes:
>>
>>> The current version of the multiarch vDSO selftest verifies only
>>> gettimeofday.
>>>
>>> Extend the vDSO selftest to clock_getres, to verify that the
>>> syscall and the vDSO library function return the same information.
>>>
>>> The extension has been used to verify the hrtimer_resoltion fix.
>>
>> This is passing for me even without patch 1 applied, shouldn't it fail
>> without the fix? What am I missing?
>>
> 
> This is correct, because during the refactoring process I missed an "n" :)
> 
> if·((x.tv_sec·!=·y.tv_sec)·||·(x.tv_sec·!=·y.tv_sec))
> 
> Should be:
> 
> if·((x.tv_sec·!=·y.tv_sec)·||·(x.tv_nsec·!=·y.tv_nsec))
> 
> My mistake, I am going to fix the test and re-post v5 of this set.
> 
> Without my patch if you pass "highres=off" to the kernel (as a command line
> parameter) it leads to a broken implementation of clock_getres since the value
> of CLOCK_REALTIME_RES does not change at runtime.
> 
> Expected result (with highres=off):
> 
> # uname -r
> 5.2.0-rc2
> # ./vdso_clock_getres
> clock_id: CLOCK_REALTIME [FAIL]
> clock_id: CLOCK_BOOTTIME [PASS]
> clock_id: CLOCK_TAI [PASS]
> clock_id: CLOCK_REALTIME_COARSE [PASS]
> clock_id: CLOCK_MONOTONIC [FAIL]
> clock_id: CLOCK_MONOTONIC_RAW [PASS]
> clock_id: CLOCK_MONOTONIC_COARSE [PASS]
> 
> The reason of this behavior is that the only clocks supported by getres on
> powerpc are CLOCK_REALTIME and CLOCK_MONOTONIC, the rest on the clocks use
> always syscalls.
> 
>> # uname -r
>> 5.2.0-rc2-gcc-8.2.0
>>
>> # ./vdso_clock_getres
>> clock_id: CLOCK_REALTIME [PASS]
>> clock_id: CLOCK_BOOTTIME [PASS]
>> clock_id: CLOCK_TAI [PASS]
>> clock_id: CLOCK_REALTIME_COARSE [PASS]
>> clock_id: CLOCK_MONOTONIC [PASS]
>> clock_id: CLOCK_MONOTONIC_RAW [PASS]
>> clock_id: CLOCK_MONOTONIC_COARSE [PASS]
>>
>> cheers
>>
>>> Cc: Shuah Khan <shuah@kernel.org>
>>> Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
>>> ---
>>>
>>> Note: This patch is independent from the others in this series, hence it
>>> can be merged singularly by the kselftest maintainers.
>>>
>>>  tools/testing/selftests/vDSO/Makefile         |   2 +
>>>  .../selftests/vDSO/vdso_clock_getres.c        | 124 ++++++++++++++++++
>>>  2 files changed, 126 insertions(+)
>>>  create mode 100644 tools/testing/selftests/vDSO/vdso_clock_getres.c
> 

WARNING: multiple messages have this Message-ID (diff)
From: Vincenzo Frascino <vincenzo.frascino@arm.com>
To: Michael Ellerman <mpe@ellerman.id.au>,
	linux-arch@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	linux-s390@vger.kernel.org, linux-kselftest@vger.kernel.org
Cc: Arnd Bergmann <arnd@arndb.de>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	Paul Mackerras <paulus@samba.org>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Shuah Khan <shuah@kernel.org>
Subject: Re: [PATCH v4 3/3] kselftest: Extend vDSO selftest to clock_getres
Date: Thu, 13 Jun 2019 16:22:49 +0100	[thread overview]
Message-ID: <5262a024-7af1-4792-ec74-4cb5f2b0e76c@arm.com> (raw)
In-Reply-To: <afb7395f-43e9-c304-2db2-349e6727b687@arm.com>

Hi Michael,

I wanted to check with you if you had time to have a look at my new version (v5)
of the patches with the fixed test, and if they are ready to be merged or if
there is anything else I can do.

Thanks and Regards,
Vincenzo

On 28/05/2019 12:57, Vincenzo Frascino wrote:
> Hi Michael,
> 
> thank you for your reply.
> 
> On 28/05/2019 07:19, Michael Ellerman wrote:
>> Vincenzo Frascino <vincenzo.frascino@arm.com> writes:
>>
>>> The current version of the multiarch vDSO selftest verifies only
>>> gettimeofday.
>>>
>>> Extend the vDSO selftest to clock_getres, to verify that the
>>> syscall and the vDSO library function return the same information.
>>>
>>> The extension has been used to verify the hrtimer_resoltion fix.
>>
>> This is passing for me even without patch 1 applied, shouldn't it fail
>> without the fix? What am I missing?
>>
> 
> This is correct, because during the refactoring process I missed an "n" :)
> 
> if·((x.tv_sec·!=·y.tv_sec)·||·(x.tv_sec·!=·y.tv_sec))
> 
> Should be:
> 
> if·((x.tv_sec·!=·y.tv_sec)·||·(x.tv_nsec·!=·y.tv_nsec))
> 
> My mistake, I am going to fix the test and re-post v5 of this set.
> 
> Without my patch if you pass "highres=off" to the kernel (as a command line
> parameter) it leads to a broken implementation of clock_getres since the value
> of CLOCK_REALTIME_RES does not change at runtime.
> 
> Expected result (with highres=off):
> 
> # uname -r
> 5.2.0-rc2
> # ./vdso_clock_getres
> clock_id: CLOCK_REALTIME [FAIL]
> clock_id: CLOCK_BOOTTIME [PASS]
> clock_id: CLOCK_TAI [PASS]
> clock_id: CLOCK_REALTIME_COARSE [PASS]
> clock_id: CLOCK_MONOTONIC [FAIL]
> clock_id: CLOCK_MONOTONIC_RAW [PASS]
> clock_id: CLOCK_MONOTONIC_COARSE [PASS]
> 
> The reason of this behavior is that the only clocks supported by getres on
> powerpc are CLOCK_REALTIME and CLOCK_MONOTONIC, the rest on the clocks use
> always syscalls.
> 
>> # uname -r
>> 5.2.0-rc2-gcc-8.2.0
>>
>> # ./vdso_clock_getres
>> clock_id: CLOCK_REALTIME [PASS]
>> clock_id: CLOCK_BOOTTIME [PASS]
>> clock_id: CLOCK_TAI [PASS]
>> clock_id: CLOCK_REALTIME_COARSE [PASS]
>> clock_id: CLOCK_MONOTONIC [PASS]
>> clock_id: CLOCK_MONOTONIC_RAW [PASS]
>> clock_id: CLOCK_MONOTONIC_COARSE [PASS]
>>
>> cheers
>>
>>> Cc: Shuah Khan <shuah@kernel.org>
>>> Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
>>> ---
>>>
>>> Note: This patch is independent from the others in this series, hence it
>>> can be merged singularly by the kselftest maintainers.
>>>
>>>  tools/testing/selftests/vDSO/Makefile         |   2 +
>>>  .../selftests/vDSO/vdso_clock_getres.c        | 124 ++++++++++++++++++
>>>  2 files changed, 126 insertions(+)
>>>  create mode 100644 tools/testing/selftests/vDSO/vdso_clock_getres.c
> 

  parent reply	other threads:[~2019-06-13 15:22 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-23 11:21 [PATCH v4 0/3] Fix vDSO clock_getres() Vincenzo Frascino
2019-05-23 11:21 ` Vincenzo Frascino
2019-05-23 11:21 ` Vincenzo Frascino
2019-05-23 11:21 ` vincenzo.frascino
2019-05-23 11:21 ` [PATCH v4 1/3] powerpc: " Vincenzo Frascino
2019-05-23 11:21   ` Vincenzo Frascino
2019-05-23 11:21   ` Vincenzo Frascino
2019-05-23 11:21   ` vincenzo.frascino
2019-05-29 13:14   ` Sasha Levin
2019-05-29 13:14     ` Sasha Levin
2019-05-23 11:21 ` [PATCH v4 2/3] s390: " Vincenzo Frascino
2019-05-23 11:21   ` Vincenzo Frascino
2019-05-23 11:21   ` Vincenzo Frascino
2019-05-23 11:21   ` vincenzo.frascino
2019-05-23 11:21 ` [PATCH v4 3/3] kselftest: Extend vDSO selftest to clock_getres Vincenzo Frascino
2019-05-23 11:21   ` Vincenzo Frascino
2019-05-23 11:21   ` Vincenzo Frascino
2019-05-23 11:21   ` vincenzo.frascino
2019-05-28  6:19   ` Michael Ellerman
2019-05-28  6:19     ` Michael Ellerman
2019-05-28  6:19     ` Michael Ellerman
2019-05-28  6:19     ` Michael Ellerman
2019-05-28  6:19     ` mpe
2019-05-28 11:57     ` Vincenzo Frascino
2019-05-28 11:57       ` Vincenzo Frascino
2019-05-28 11:57       ` Vincenzo Frascino
2019-05-28 11:57       ` vincenzo.frascino
2019-05-28 17:01       ` Christophe Leroy
2019-05-28 17:01         ` Christophe Leroy
2019-05-28 17:01         ` Christophe Leroy
2019-05-28 17:01         ` christophe.leroy
2019-05-28 17:05         ` Vincenzo Frascino
2019-05-28 17:05           ` Vincenzo Frascino
2019-05-28 17:05           ` Vincenzo Frascino
2019-05-28 17:05           ` vincenzo.frascino
2019-06-04 13:16       ` Christophe Leroy
2019-06-04 13:16         ` Christophe Leroy
2019-06-04 13:16         ` Christophe Leroy
2019-06-04 13:16         ` christophe.leroy
2019-06-04 13:32         ` Vincenzo Frascino
2019-06-04 13:32           ` Vincenzo Frascino
2019-06-04 13:32           ` Vincenzo Frascino
2019-06-04 13:32           ` vincenzo.frascino
2019-06-04 13:39           ` Christophe Leroy
2019-06-04 13:39             ` Christophe Leroy
2019-06-04 13:39             ` Christophe Leroy
2019-06-04 13:39             ` christophe.leroy
2019-06-04 13:43             ` Vincenzo Frascino
2019-06-04 13:43               ` Vincenzo Frascino
2019-06-04 13:43               ` Vincenzo Frascino
2019-06-04 13:43               ` vincenzo.frascino
2019-06-04 13:52               ` Christophe Leroy
2019-06-04 13:52                 ` Christophe Leroy
2019-06-04 13:52                 ` Christophe Leroy
2019-06-04 13:52                 ` christophe.leroy
2019-06-04 14:21                 ` Vincenzo Frascino
2019-06-04 14:21                   ` Vincenzo Frascino
2019-06-04 14:21                   ` Vincenzo Frascino
2019-06-04 14:21                   ` vincenzo.frascino
2019-06-13 15:22       ` Vincenzo Frascino [this message]
2019-06-13 15:22         ` Vincenzo Frascino

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5262a024-7af1-4792-ec74-4cb5f2b0e76c@arm.com \
    --to=vincenzo.frascino@arm.com \
    --cc=arnd@arndb.de \
    --cc=benh@kernel.crashing.org \
    --cc=christophe.leroy@c-s.fr \
    --cc=heiko.carstens@de.ibm.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=paulus@samba.org \
    --cc=schwidefsky@de.ibm.com \
    --cc=shuah@kernel.org \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.