public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Adhemerval Zanella <adhemerval.zanella@linaro.org>
To: Szabolcs Nagy <szabolcs.nagy@arm.com>, libc-alpha@sourceware.org
Cc: nd@arm.com, Steve Ellcey <sellcey@cavium.com>
Subject: Re: [Patch] Use VDSO interface for gettimeofday on aarch64
Date: Wed, 16 May 2018 13:23:00 -0000	[thread overview]
Message-ID: <0f469ef9-cac6-a07d-b61e-ba02236e7e84@linaro.org> (raw)
In-Reply-To: <bb07d192-e6d5-4512-d29f-667af907c202@arm.com>



On 16/05/2018 09:12, Szabolcs Nagy wrote:
> On 16/05/18 13:03, Szabolcs Nagy wrote:
>> On 16/05/18 12:51, Adhemerval Zanella wrote:
>>> On 16/05/2018 07:44, Szabolcs Nagy wrote:
>>>> The other thing that would be nice to document is that
>>>> why this change is safe for gettimeofday but not clock_gettime.
>>>> (former does not have to set errno other than EFAULT but that
>>>> case never works with vdso anyway, so the gettimeofday vdso
>>>> function is a complete implementation, while clock_gettime
>>>> has to deal with errno after the vdso call)
>>>
>>> As I put previously keep in mind that different that x86 and powerpc
>>> implementations, where the vDSO symbol does not fail; the arm64 vDSO
>>> implements a syscall fallback in case of underlying hardware requires
>>> an out-of-line counter access (arch_timer_enable_workaround).
>>>
>>> Using a ifunc accessors to call vDSO directly will result in a slight
>>> different semantic since generic implementation (kernel/time/time.c)
>>> might return EFAULT in some cases (which won't be handled by ifunc
>>> implementation).  This should not be an issue since POSIX [1] defines
>>> no error code should reserved for the symbol, but it might trigger
>>> some test in LTP.
>>>
>>
>> sorry i missed this comment,
>>
>> if the vdso can fail with -EFAULT then this optimization is not valid
>> (gettimeofday must either return 0 or -1).
>>
>> if userspace can test whatever the kernel is testing there, that
>> could be added to the ifunc resolver and only use vdso if we know
>> it does not fail (i don't know if this is possible).
>>
> 
> hm in posix EFAULT is not a requirement, it's probably
> undefined behaviour if gettimeofday is called with
> wrong pointers. (this is borderline since linux man
> pages document the EFAULT, but obviously that cannot
> work for vdso anyway)
> 
> then the optimization is ok, but we definitely need
> to document why we think directly going to the vdso
> is safe.

I think the optimization is fine as well, we had previous discussion about some
syscall semantics returning EFAULT [1] (which also lead to LTP test fixes [2]),
and the generic idea was since is UB to rely on EFAULT return code (for instance
a call to 'gettimeofday (0, 0)') it is fine to glibc also change semantic if it
finds suitable.

[1] https://sourceware.org/ml/libc-alpha/2017-10/msg00830.html
[2] https://github.com/linux-test-project/ltp/commit/259db6fed55f88ab32a0875e66803eee44d298be

  reply	other threads:[~2018-05-16 13:23 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-10 18:01 Steve Ellcey
2018-05-11  0:28 ` Jonathan Nieder
2018-05-11  4:05 ` Siddhesh Poyarekar
2018-05-11  4:44   ` Andrew Pinski
2018-05-11  5:51     ` Siddhesh Poyarekar
2018-05-11 11:16 ` Szabolcs Nagy
2018-05-15 23:07   ` Steve Ellcey
2018-05-16 10:44     ` Szabolcs Nagy
2018-05-16 11:52       ` Adhemerval Zanella
2018-05-16 12:03         ` Szabolcs Nagy
2018-05-16 12:13           ` Szabolcs Nagy
2018-05-16 13:23             ` Adhemerval Zanella [this message]
2018-05-22 20:26       ` Steve Ellcey
2018-06-14 13:03         ` [COMMITTED] aarch64: Use an ifunc/VDSO to implement gettimeofday in shared glibc Szabolcs Nagy
2018-06-14 16:59           ` Steve Ellcey

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=0f469ef9-cac6-a07d-b61e-ba02236e7e84@linaro.org \
    --to=adhemerval.zanella@linaro.org \
    --cc=libc-alpha@sourceware.org \
    --cc=nd@arm.com \
    --cc=sellcey@cavium.com \
    --cc=szabolcs.nagy@arm.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).