Received: by 2002:a25:d7c1:0:0:0:0:0 with SMTP id o184csp1805181ybg; Sat, 19 Oct 2019 02:54:02 -0700 (PDT) X-Google-Smtp-Source: APXvYqwIck78Z0NTwiEto5jeNVxGsRmVGj1CSeC3cRVsBUO94cyxq/E2f12OxyD6vZx9P1ZwHm/F X-Received: by 2002:a50:ed01:: with SMTP id j1mr14332650eds.111.1571478841896; Sat, 19 Oct 2019 02:54:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1571478841; cv=none; d=google.com; s=arc-20160816; b=l+sDLim1aka9k78W+7+dfTdNj4GnEdthD/5oWFBkPqnGVMgSODqoFhSbT3KFqTJib0 Y/KL2pcEHuBMy7bmOvzaTCRFBb4qQ6FIpCvkC5xsQhDL0cZPl3rQukb1zxO6vhKtwl3I 02+7SgWtSlf7kQrXh+AmdiGn9naFEiw/r6tel1Jr8IB/KMexfT945aHnidktXPmuZTiP 8GBBJJY3w0Y/8XL3QGPrs8hagvXmjPrxtPUZ/lyApAZa9D/Y6Oty70Ka8ioQJBPZ+0yS +mGssiGWUlwaMhqKPmKEc1zqvwE35PcdiX5qkfLnYfRrJW+CGFDxsUM27qW1y/hp2G+d ziVQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version; bh=h2Om4jrmaYSV3RVSH6Bll8Mfy0zcDVPMDEzdsJPKN50=; b=iAFWm/wBpOxNsb6TjHbjxjFTdyZfJbWEfgn8iiJ/1oWwMPosp4l7xntr/FQFIas/yC j40lCHq6VCeY9LV1DzlsKrUxfLryEZwzW5hNBAzfZEtVquOuEz72i/V4e9yewduYJR/Z zGs2lZAcmIU+3//B770uxIoTQ2a7jF/Mu3ZeftzRe4T9+3tSwtt/1HhEbiD8+BPCRxxr 6Xa4XllxBpu5Rlxm/5A8DF7jWsEORZeVXXuwkM1151p6FQoSYZbpcJVVmeP5r3lulsmY 8Qhi+Iat3R1QG4YhQgvHxP75+2Ms0chOxRRTUFkwt0A16L0fg62YaTUEwLTYY5TE0Vvv 1CgQ== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n17si4924918edo.143.2019.10.19.02.53.38; Sat, 19 Oct 2019 02:54:01 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726759AbfJSCBW (ORCPT + 99 others); Fri, 18 Oct 2019 22:01:22 -0400 Received: from mail-io1-f66.google.com ([209.85.166.66]:34002 "EHLO mail-io1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726033AbfJSCBV (ORCPT ); Fri, 18 Oct 2019 22:01:21 -0400 Received: by mail-io1-f66.google.com with SMTP id q1so9691348ion.1; Fri, 18 Oct 2019 19:01:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=h2Om4jrmaYSV3RVSH6Bll8Mfy0zcDVPMDEzdsJPKN50=; b=FksOxxu2bx2/tUZaoTAY24KwqRmLnzOCbxsJfqC3PGiDIlTnw3uUj9yS9AuWW1p0Da ZkNFN+Jb19tYrz5Fk8sfz9tODFfrEffcIXoM8wOL59g1UC/RKyeSg+cLkUGI68r3y9i8 0Yyr05+/soI+KJUIFx5xnhza82740QUvpaYgliHvIY1os+e5kneDust13D7HKewZfKhi hcxVhZzYX2aO0Dzll5SFA0ZxXmtgvF7P8+NMty4KSUbHWZAi2/pFdhOYjfEld5WVtiMN 02Bhy9GPN40I3lpPpUBg7e0Q0fjlrAWjQpU9K48Py9d/4mk4NlQhH6zzcyZwOsjkvGNu QE5A== X-Gm-Message-State: APjAAAXxim+o+rYrZd1kz46/nJ1PBhAMh95fFNrgx8S4YtlR5aDNwxp7 FOXl7F7h29X+vHJSbB/s+BUVf/gpqYfO/JafGyE= X-Received: by 2002:a6b:5c0f:: with SMTP id z15mr11805568ioh.173.1571450479050; Fri, 18 Oct 2019 19:01:19 -0700 (PDT) MIME-Version: 1.0 References: <1571367619-13573-1-git-send-email-chenhc@lemote.com> In-Reply-To: From: Huacai Chen Date: Sat, 19 Oct 2019 10:06:42 +0800 Message-ID: Subject: Re: [PATCH] lib/vdso: Use __arch_use_vsyscall() to indicate fallback To: Andy Lutomirski Cc: Thomas Gleixner , Vincenzo Frascino , LKML , stable , Arnd Bergmann , Paul Burton , "open list:MIPS" , linux-arm-kernel Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Andy, On Fri, Oct 18, 2019 at 11:15 AM Andy Lutomirski wrote: > > On Thu, Oct 17, 2019 at 7:57 PM Huacai Chen wrote: > > > > In do_hres(), we currently use whether the return value of __arch_get_ > > hw_counter() is negtive to indicate fallback, but this is not a good > > idea. Because: > > > > 1, ARM64 returns ULL_MAX but MIPS returns 0 when clock_mode is invalid; > > 2, For a 64bit counter, a "negtive" value of counter is actually valid. > > s/negtive/negative > > What's the actual bug? Is it that MIPS is returning 0 but the check > is < 0? Sounds like MIPS should get fixed. My original bug is what Vincenzo said, MIPS has a boot failure if no valid clock_mode, and surely MIPS need to fix. However, when I try to fix it, I found that clock_getres() has another problem, because __cvdso_clock_getres_common() get vd[CS_HRES_COARSE].hrtimer_res, but hrtimer_res is set in update_vdso_data() which relies on __arch_use_vsyscall(). > > > > > To solve this problem, we use U64_MAX as the only "invalid" return > > value -- this is still not fully correct, but has no problem in most > > cases. > > I'm sort of okay with that, but... > > > Moreover, all vdso time-related functions should rely on the > > return value of __arch_use_vsyscall(), because update_vdso_data() and > > update_vsyscall_tz() also rely on it. So, in the core functions of > > __cvdso_gettimeofday(), __cvdso_clock_gettime() and __cvdso_clock_ > > getres(), if __arch_use_vsyscall() returns false, we use the fallback > > functions directly. > > __arch_use_vsyscall() is not currently intended for use in the vDSO at all. > > > > > Fixes: 00b26474c2f1613d7ab894c5 ("lib/vdso: Provide generic VDSO implementation") > > Cc: stable@vger.kernel.org > > Cc: Arnd Bergmann > > Cc: Paul Burton > > Cc: linux-mips@vger.kernel.org > > Cc: linux-arm-kernel@lists.infradead.org > > Signed-off-by: Huacai Chen > > --- > > arch/arm64/include/asm/vdso/vsyscall.h | 2 +- > > arch/mips/include/asm/vdso/vsyscall.h | 2 +- > > include/asm-generic/vdso/vsyscall.h | 2 +- > > lib/vdso/gettimeofday.c | 12 +++++++++++- > > 4 files changed, 14 insertions(+), 4 deletions(-) > > > > diff --git a/arch/arm64/include/asm/vdso/vsyscall.h b/arch/arm64/include/asm/vdso/vsyscall.h > > index 0c731bf..406e6de 100644 > > --- a/arch/arm64/include/asm/vdso/vsyscall.h > > +++ b/arch/arm64/include/asm/vdso/vsyscall.h > > @@ -31,7 +31,7 @@ int __arm64_get_clock_mode(struct timekeeper *tk) > > #define __arch_get_clock_mode __arm64_get_clock_mode > > > > static __always_inline > > -int __arm64_use_vsyscall(struct vdso_data *vdata) > > +int __arm64_use_vsyscall(const struct vdso_data *vdata) > > { > > return !vdata[CS_HRES_COARSE].clock_mode; > > } > > diff --git a/arch/mips/include/asm/vdso/vsyscall.h b/arch/mips/include/asm/vdso/vsyscall.h > > index 1953147..8b10dd7 100644 > > --- a/arch/mips/include/asm/vdso/vsyscall.h > > +++ b/arch/mips/include/asm/vdso/vsyscall.h > > @@ -29,7 +29,7 @@ int __mips_get_clock_mode(struct timekeeper *tk) > > #define __arch_get_clock_mode __mips_get_clock_mode > > > > static __always_inline > > -int __mips_use_vsyscall(struct vdso_data *vdata) > > +int __mips_use_vsyscall(const struct vdso_data *vdata) > > { > > return (vdata[CS_HRES_COARSE].clock_mode != VDSO_CLOCK_NONE); > > } > > diff --git a/include/asm-generic/vdso/vsyscall.h b/include/asm-generic/vdso/vsyscall.h > > index e94b1978..ac05a625 100644 > > --- a/include/asm-generic/vdso/vsyscall.h > > +++ b/include/asm-generic/vdso/vsyscall.h > > @@ -26,7 +26,7 @@ static __always_inline int __arch_get_clock_mode(struct timekeeper *tk) > > #endif /* __arch_get_clock_mode */ > > > > #ifndef __arch_use_vsyscall > > -static __always_inline int __arch_use_vsyscall(struct vdso_data *vdata) > > +static __always_inline int __arch_use_vsyscall(const struct vdso_data *vdata) > > { > > return 1; > > } > > diff --git a/lib/vdso/gettimeofday.c b/lib/vdso/gettimeofday.c > > index e630e7f..4ad062e 100644 > > --- a/lib/vdso/gettimeofday.c > > +++ b/lib/vdso/gettimeofday.c > > @@ -9,6 +9,7 @@ > > #include > > #include > > #include > > +#include > > > > /* > > * The generic vDSO implementation requires that gettimeofday.h > > @@ -50,7 +51,7 @@ static int do_hres(const struct vdso_data *vd, clockid_t clk, > > cycles = __arch_get_hw_counter(vd->clock_mode); > > ns = vdso_ts->nsec; > > last = vd->cycle_last; > > - if (unlikely((s64)cycles < 0)) > > + if (unlikely(cycles == U64_MAX)) > > return -1; > > I would actually prefer: > > if (unlikely(cycles < last)) > > or perhaps: > > if (unlikely((s64)(cycles-last) < 0)) > > which would have the nice side effect of getting rid of the annoying > x86 special case in vdso_calc_delta(). The former version is > compatible with U64_MAX, whereas the latter version would need the > error case to return last-1 or similar. The benefit of the latter > version is that it can survive wrap-around. When you say if (unlikely(cycles < last)), do you means if (unlikely(cycles <= last))? If __arch_get_hw_counter() return U64_MAX every time, I don't think cycles can be less than last. Huacai > > > > > ns += vdso_calc_delta(cycles, last, vd->mask, vd->mult); > > @@ -91,6 +92,9 @@ __cvdso_clock_gettime_common(clockid_t clock, struct __kernel_timespec *ts) > > if (unlikely((u32) clock >= MAX_CLOCKS)) > > return -1; > > > > + if (!__arch_use_vsyscall(vd)) > > + return -1; > > + > > NAK. I don't think this is helpful or correct. It doesn't appear to > do anything valid, and it's racy. > > > /* > > * Convert the clockid to a bitmask and use it to check which > > * clocks are handled in the VDSO directly. > > @@ -145,6 +149,9 @@ __cvdso_gettimeofday(struct __kernel_old_timeval *tv, struct timezone *tz) > > { > > const struct vdso_data *vd = __arch_get_vdso_data(); > > > > + if (!__arch_use_vsyscall(vd)) > > + return gettimeofday_fallback(tv, tz); > > + > > Ditto. > > > if (likely(tv != NULL)) { > > struct __kernel_timespec ts; > > > > @@ -189,6 +196,9 @@ int __cvdso_clock_getres_common(clockid_t clock, struct __kernel_timespec *res) > > if (unlikely((u32) clock >= MAX_CLOCKS)) > > return -1; > > > > + if (!__arch_use_vsyscall(vd)) > > + return -1; > > + > > Ditto.