From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: devel@linuxdriverproject.org, linux-kernel@vger.kernel.org,
"K. Y. Srinivasan" <kys@microsoft.com>,
Haiyang Zhang <haiyangz@microsoft.com>,
John Stultz <john.stultz@linaro.org>,
Thomas Gleixner <tglx@linutronix.de>,
Alex Ng <alexng@microsoft.com>
Subject: Re: [PATCH v2 4/4] hv_util: improve time adjustment accuracy by disabling interrupts
Date: Thu, 05 Jan 2017 13:35:58 +0100 [thread overview]
Message-ID: <87o9zladld.fsf@vitty.brq.redhat.com> (raw)
In-Reply-To: <20170104111749.0e7d566e@xeon-e3> (Stephen Hemminger's message of "Wed, 4 Jan 2017 11:17:49 -0800")
Stephen Hemminger <stephen@networkplumber.org> writes:
> On Wed, 4 Jan 2017 18:24:39 +0100
> Vitaly Kuznetsov <vkuznets@redhat.com> wrote:
>
>> If we happen to receive interrupts during hv_set_host_time() execution
>> our adjustments may get inaccurate. Make the whole function atomic.
>> Unfortunately, we can's call do_settimeofday64() with interrupts
>> disabled as some cross-CPU work is being done but this call happens
>> very rarely.
>>
>> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
>
> Ok, the race is between timer interrupts and calling do_adjtimex().
> NTP has the same issue already.
>
> The getnstimeofday64() (or ktime_get) return an atomic value.
> If a clock tick interrupt happens during this code, then the value
> is still correct just old.
>
> If you want to avoid all races here, it looks like it would
> be better to get timekeeper_lock and call __do_adjtimex. The existing
> code in do_adjtimex() is expecting to be called from a system call
> and changing it's assumptions is probably not a good idea.
>
I was thinking about it but to me what do_adjtimex() does looks too
low-level for drivers (e.g. calling write_seqcount_begin(),
__timekeeping_set_tai_offset(), tk_update_leap_state()). To me (again, I
probably know not that much about time keeping) it looks like we'll have
to have all this stuff around the __do_adjtimex() call here.
Are there any particular concearns on calling do_adjtimex() directly?
Yes, it was written for syscalls but I don't see any other required
things in adjtimex syscall, it's just a straitforward copy_from_user()
-> do_adjtimex() -> copy_to_user() chain.
I would very much appreciate if Thomas or John could comment what's
better here long-term.
> Rather than calling system call from user space. Maybe better
> to provide real kernel API in time subsystem for this use case.
> What does KVM do?
KVM doesn't have an NTP-like service, it just provides kvm_clock (which,
BTW, implements VCLOCK_PVCLOCK for vDSO calls -- unlike Hyper-V's TSC
page). hv_utils is going to be the first in-kernel 'NTP'.
--
Vitaly
next prev parent reply other threads:[~2017-01-05 12:36 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-04 17:24 [PATCH v2 0/4] hv_util: adjust system time smoothly Vitaly Kuznetsov
2017-01-04 17:24 ` [PATCH v2 1/4] timekeeping: export do_adjtimex() to modules Vitaly Kuznetsov
2017-01-07 1:06 ` John Stultz
2017-01-09 13:03 ` Vitaly Kuznetsov
2017-01-04 17:24 ` [PATCH v2 2/4] hv_util: switch to using timespec64 Vitaly Kuznetsov
2017-01-07 1:04 ` John Stultz
2017-01-04 17:24 ` [PATCH v2 3/4] hv_util: use do_adjtimex() to update system time Vitaly Kuznetsov
2017-01-04 19:09 ` Stephen Hemminger
2017-01-05 12:37 ` Vitaly Kuznetsov
2017-01-07 0:56 ` John Stultz
2017-01-04 17:24 ` [PATCH v2 4/4] hv_util: improve time adjustment accuracy by disabling interrupts Vitaly Kuznetsov
2017-01-04 19:17 ` Stephen Hemminger
2017-01-05 12:35 ` Vitaly Kuznetsov [this message]
2017-01-05 17:39 ` Stephen Hemminger
2017-01-07 1:02 ` John Stultz
2017-01-09 13:05 ` Vitaly Kuznetsov
2017-01-09 21:27 ` [PATCH v2 0/4] hv_util: adjust system time smoothly Thomas Gleixner
2017-01-10 14:30 ` Vitaly Kuznetsov
2017-01-10 14:58 ` Thomas Gleixner
2017-01-13 13:05 ` [PATCH RFC] hv_utils: implement Hyper-V PTP source Vitaly Kuznetsov
2017-01-13 14:50 ` Richard Cochran
2017-01-13 15:38 ` Vitaly Kuznetsov
2017-01-13 15:21 ` Olaf Hering
2017-01-13 15:37 ` Vitaly Kuznetsov
2017-01-16 19:29 ` Thomas Gleixner
2017-01-17 9:53 ` Vitaly Kuznetsov
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=87o9zladld.fsf@vitty.brq.redhat.com \
--to=vkuznets@redhat.com \
--cc=alexng@microsoft.com \
--cc=devel@linuxdriverproject.org \
--cc=haiyangz@microsoft.com \
--cc=john.stultz@linaro.org \
--cc=kys@microsoft.com \
--cc=linux-kernel@vger.kernel.org \
--cc=stephen@networkplumber.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox