Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp1236725ybl; Thu, 22 Aug 2019 11:23:31 -0700 (PDT) X-Google-Smtp-Source: APXvYqwmgifXMAfenGBT3UGo1MwTsmexAHoXs8F3QMzEmzsWxi/33RrYgLVW1dERJrwJwl5jZuv2 X-Received: by 2002:a63:b20f:: with SMTP id x15mr468532pge.453.1566498210852; Thu, 22 Aug 2019 11:23:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1566498210; cv=none; d=google.com; s=arc-20160816; b=P84JOMEIMfWLt0w+18MXl+KfJRoU/z/NREWoaRK53Ntg2ZW9ol8yOnpddF1b+O6gTM xAdlPq0VofqFRiFrhbfNvV+7xnOQLIVT/GD58cRp3hIPqn7eXa6v6t/7RqS+3N7XjqIU lNfTNJnyNvHt2m5era13GwfA3DDYbj+sEpLFvVAnIYT9xKBgmffoWRx6heDwiApYLsyf 4lUeL1o2ywMjdQ6ox25Jfp1BsICMLwHEKVJ/PdG08rKdjch3sxfLzNPxYmLbMrUzpUEO AemMRJBfVwT8dWYaw6OafsUX8OLyhcCsjzP89+KqrV0km+BCMkzPHVyxEOBuOaOeQxdN vS6g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=H61P4kK/K4tGz1R4tfrlc56EmV7OttW441kLxv64KE0=; b=qtuwjuPmIdDziQlrnig9gwqNMDQNQ7Kwcy4md3h9HtHFgr5jOcn9MGtCf2CBu4i6WK WMZFTvAWmpGACy6UNhemkX/gkV5md7PXVQQfwZS1QmbDc06k7CgUwpIwWUUwE8usvoz9 0HThNMsPRLScGW4s/5EFRBP2SKSuthQC5dnB+847s+6d4IEYYWQmORW750BOnKPC8csI mpD2a76UCrWcy8n9pfCpHVZqGynfA8txMuQbRKqOfsrHiDr9hjymMz7JlfX11YJ7mxq4 1+Y4xEZEBEw3MGfQET26uGPqE7htaXgEciVVFnU25a506QJy5yQFIjfm99VxzrjWxX1R ngdQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@googlemail.com header.s=20161025 header.b=PGXN2z3f; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=googlemail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z193si50075pgd.235.2019.08.22.11.23.15; Thu, 22 Aug 2019 11:23:30 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@googlemail.com header.s=20161025 header.b=PGXN2z3f; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=googlemail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388734AbfHVMwr (ORCPT + 99 others); Thu, 22 Aug 2019 08:52:47 -0400 Received: from mail-wr1-f67.google.com ([209.85.221.67]:37724 "EHLO mail-wr1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725856AbfHVMwr (ORCPT ); Thu, 22 Aug 2019 08:52:47 -0400 Received: by mail-wr1-f67.google.com with SMTP id z11so5327486wrt.4 for ; Thu, 22 Aug 2019 05:52:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=H61P4kK/K4tGz1R4tfrlc56EmV7OttW441kLxv64KE0=; b=PGXN2z3fTIzAxngbarEWSdoGuq4pfZE8ojsdUZnt3y3cu79vSZncqeyyUwrSdafU9V WwRPwHZ75X3dlRuB7KP7M+kYevKT1k2vdVej3xcjFWYEftLG5T/d18i17Xds+hH3t2LH 779PtIuq8ubXD3qutVVTfNsRPSwcnoLC3qXjGyLjf0vXBxapXOUlA0HfF/qCSGKbOmvP lGQ8arBxvC8RviZuvJsOAVoIOO70cxiHTTIiM32KzJ5uwDCiC+F+rtvB46vVHEjo+NTo 34X/em+KdzLVDP6t93AHxc/BAzHh55jhVJDnlb5vyuXCSXyYYVkdaBlQMFF1Esqvz8YJ Hpxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=H61P4kK/K4tGz1R4tfrlc56EmV7OttW441kLxv64KE0=; b=WxB1nCWA4yi7rqP1s/jlMNbVJTk6PHyihAmhajMngVWH9ggKAaJN2//0wBuriOuaRx ER+6IIOS+w3kEjNuWHQYKCN9DlGOXrCeotHGwrJ4nI2NByFiXaJWfE0ygY0DUQfSvMjC jnJ+7/TvKkimuka5MoarzTkE0b9VuhvXnl7TelQhWIHKNnPAY6NgOj5MuWNxxMo8dCf7 fYWir/IrS01F96kBXjY18iKs/VLfYDktq8S0vFQ+WcLx5FzHK57I6nHtPybdaqkCsyd+ Q5OPpUXg4ufNDKz5BgGf7krMWg+f8srgf2Gvuus2A5mBfeiTSsz/GTrlyt4Bb3AEiX3A 75SA== X-Gm-Message-State: APjAAAXnrdlocQJOxQ7+XU20r/j+DgZbnUUNwQRaxbFH6RT6HLWUiomj IGOSK39IVxMf53lFPWllHvE= X-Received: by 2002:adf:a55d:: with SMTP id j29mr4919284wrb.275.1566478364086; Thu, 22 Aug 2019 05:52:44 -0700 (PDT) Received: from [192.168.1.20] (host109-153-59-46.range109-153.btcentralplus.com. [109.153.59.46]) by smtp.googlemail.com with ESMTPSA id a18sm28812434wrt.18.2019.08.22.05.52.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 22 Aug 2019 05:52:43 -0700 (PDT) Subject: Re: [PATCH] timekeeping/vsyscall: Prevent math overflow in BOOTTIME update To: Thomas Gleixner Cc: LKML , vincenzo.frascino@arm.com, catalin.marinas@arm.com, Will Deacon , Arnd Bergmann , Daniel Lezcano , Andy Lutomirski References: From: Chris Clayton Message-ID: <652e3ca3-38ed-7969-fcc5-3d128879fb38@googlemail.com> Date: Thu, 22 Aug 2019 13:52:40 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Thanks Thomas. On 22/08/2019 12:00, Thomas Gleixner wrote: > The VDSO update for CLOCK_BOOTTIME has a overflow issue as it shifts the > nanoseconds based boot time offset left by the clocksource shift. That > overflows once the boot time offset becomes large enough. As a consequence > CLOCK_BOOTTIME in the VDSO becomes a random number causing applications to > misbehave. > > Fix it by storing a timespec64 representation of the offset when boot time > is adjusted and add that to the MONOTONIC base time value in the vdso data > page. Using the timespec64 representation avoids a 64bit division in the > update code. > I've tested resume from both suspend and hibernate and this patch fixes the problem I reported. Tested-by: Chris Clayton > Fixes: 44f57d788e7d ("timekeeping: Provide a generic update_vsyscall() implementation") > Reported-by: Chris Clayton > Signed-off-by: Thomas Gleixner > --- > include/linux/timekeeper_internal.h | 5 +++++ > kernel/time/timekeeping.c | 5 +++++ > kernel/time/vsyscall.c | 22 +++++++++++++--------- > 3 files changed, 23 insertions(+), 9 deletions(-) > > --- a/include/linux/timekeeper_internal.h > +++ b/include/linux/timekeeper_internal.h > @@ -57,6 +57,7 @@ struct tk_read_base { > * @cs_was_changed_seq: The sequence number of clocksource change events > * @next_leap_ktime: CLOCK_MONOTONIC time value of a pending leap-second > * @raw_sec: CLOCK_MONOTONIC_RAW time in seconds > + * @monotonic_to_boot: CLOCK_MONOTONIC to CLOCK_BOOTTIME offset > * @cycle_interval: Number of clock cycles in one NTP interval > * @xtime_interval: Number of clock shifted nano seconds in one NTP > * interval. > @@ -84,6 +85,9 @@ struct tk_read_base { > * > * wall_to_monotonic is no longer the boot time, getboottime must be > * used instead. > + * > + * @monotonic_to_boottime is a timespec64 representation of @offs_boot to > + * accelerate the VDSO update for CLOCK_BOOTTIME. > */ > struct timekeeper { > struct tk_read_base tkr_mono; > @@ -99,6 +103,7 @@ struct timekeeper { > u8 cs_was_changed_seq; > ktime_t next_leap_ktime; > u64 raw_sec; > + struct timespec64 monotonic_to_boot; > > /* The following members are for timekeeping internal use */ > u64 cycle_interval; > --- a/kernel/time/timekeeping.c > +++ b/kernel/time/timekeeping.c > @@ -146,6 +146,11 @@ static void tk_set_wall_to_mono(struct t > static inline void tk_update_sleep_time(struct timekeeper *tk, ktime_t delta) > { > tk->offs_boot = ktime_add(tk->offs_boot, delta); > + /* > + * Timespec representation for VDSO update to avoid 64bit division > + * on every update. > + */ > + tk->monotonic_to_boot = ktime_to_timespec64(tk->offs_boot); > } > > /* > --- a/kernel/time/vsyscall.c > +++ b/kernel/time/vsyscall.c > @@ -17,7 +17,7 @@ static inline void update_vdso_data(stru > struct timekeeper *tk) > { > struct vdso_timestamp *vdso_ts; > - u64 nsec; > + u64 nsec, sec; > > vdata[CS_HRES_COARSE].cycle_last = tk->tkr_mono.cycle_last; > vdata[CS_HRES_COARSE].mask = tk->tkr_mono.mask; > @@ -45,23 +45,27 @@ static inline void update_vdso_data(stru > } > vdso_ts->nsec = nsec; > > - /* CLOCK_MONOTONIC_RAW */ > - vdso_ts = &vdata[CS_RAW].basetime[CLOCK_MONOTONIC_RAW]; > - vdso_ts->sec = tk->raw_sec; > - vdso_ts->nsec = tk->tkr_raw.xtime_nsec; > + /* Copy MONOTONIC time for BOOTTIME */ > + sec = vdso_ts->sec; > + /* Add the boot offset */ > + sec += tk->monotonic_to_boot.tv_sec; > + nsec += (u64)tk->monotonic_to_boot.tv_nsec << tk->tkr_mono.shift; > > /* CLOCK_BOOTTIME */ > vdso_ts = &vdata[CS_HRES_COARSE].basetime[CLOCK_BOOTTIME]; > - vdso_ts->sec = tk->xtime_sec + tk->wall_to_monotonic.tv_sec; > - nsec = tk->tkr_mono.xtime_nsec; > - nsec += ((u64)(tk->wall_to_monotonic.tv_nsec + > - ktime_to_ns(tk->offs_boot)) << tk->tkr_mono.shift); > + vdso_ts->sec = sec; > + > while (nsec >= (((u64)NSEC_PER_SEC) << tk->tkr_mono.shift)) { > nsec -= (((u64)NSEC_PER_SEC) << tk->tkr_mono.shift); > vdso_ts->sec++; > } > vdso_ts->nsec = nsec; > > + /* CLOCK_MONOTONIC_RAW */ > + vdso_ts = &vdata[CS_RAW].basetime[CLOCK_MONOTONIC_RAW]; > + vdso_ts->sec = tk->raw_sec; > + vdso_ts->nsec = tk->tkr_raw.xtime_nsec; > + > /* CLOCK_TAI */ > vdso_ts = &vdata[CS_HRES_COARSE].basetime[CLOCK_TAI]; > vdso_ts->sec = tk->xtime_sec + (s64)tk->tai_offset; >