From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1161445AbdAEMgL (ORCPT ); Thu, 5 Jan 2017 07:36:11 -0500 Received: from mx1.redhat.com ([209.132.183.28]:41818 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1033663AbdAEMgB (ORCPT ); Thu, 5 Jan 2017 07:36:01 -0500 From: Vitaly Kuznetsov To: Stephen Hemminger Cc: devel@linuxdriverproject.org, linux-kernel@vger.kernel.org, "K. Y. Srinivasan" , Haiyang Zhang , John Stultz , Thomas Gleixner , Alex Ng Subject: Re: [PATCH v2 4/4] hv_util: improve time adjustment accuracy by disabling interrupts References: <20170104172439.19683-1-vkuznets@redhat.com> <20170104172439.19683-5-vkuznets@redhat.com> <20170104111749.0e7d566e@xeon-e3> Date: Thu, 05 Jan 2017 13:35:58 +0100 In-Reply-To: <20170104111749.0e7d566e@xeon-e3> (Stephen Hemminger's message of "Wed, 4 Jan 2017 11:17:49 -0800") Message-ID: <87o9zladld.fsf@vitty.brq.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Thu, 05 Jan 2017 12:36:02 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Stephen Hemminger writes: > On Wed, 4 Jan 2017 18:24:39 +0100 > Vitaly Kuznetsov 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 > > 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