Received: by 2002:a25:d7c1:0:0:0:0:0 with SMTP id o184csp1811833ybg; Sat, 19 Oct 2019 03:02:19 -0700 (PDT) X-Google-Smtp-Source: APXvYqzzKwJr1UY/5L2eRGyDTUJ348esydIAVi4V3pYSUPQ14oKPyW2zPLPekyavlYlbG146TnqQ X-Received: by 2002:a50:ce06:: with SMTP id y6mr14393493edi.259.1571479338956; Sat, 19 Oct 2019 03:02:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1571479338; cv=none; d=google.com; s=arc-20160816; b=ETsqssdvu01ssBj1yFHzXBbLwu7NlyTQS9yEqlQJapK7M9fDbPqQMt+1SbH6WIU0sS KImzn7Y77nnNGDtpaoSYyV5c22pyDzKofLpjlZ4lCBSPlVzHG8KpFmGfHeoxLx/JN+Qs lub4ycjSKi7+nFzrXvAWEbyeOEGxcTDnYHNh/MzaFlmewDWypsuSt2qx/BFPNFc8yL6V bD+obdgNbhNWYUizZI1JDXSoGAF4+Pgu5Y1ehNa2YCUd1LuV2pJjJ5jsQj1pA4mTvR1i PsGbAbQQpRtgciKqb6QhH7DwkKKEUAa1u4K5v3iW4LITc4uvsKXBToJqcouu+PE0ZlV0 HuLw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=2Mwt7B8S5xDTZQbaKV95zTadOAT+JVLMmy6wLAGwMHY=; b=aqTLneB5MPGCy3a76oTVFLqw4H0yQ1acQR1ivtOSSzYfDvKX/D1JTj0LJlVSuyGUiP A0IkoHEo4qkgEvb8C6sGMTLSHvtJJuuU95zRD3HOt0DHmH3tcJioT+AxyMUR51QqpW64 u4IbYHj8znACRuu/CKu0+7R24HvWsnz7RZ9iU/iiWpR52ewZPR9TYjivnL02WUAJytkk JwGYHSmZvIqpEM+yZ93qMcjY5jQvBbP8iyujYclQub0Dqox1GDX8eWVKJe0XS4wahBnk 1aLzB9OswKpbEytpXRDcRVDjwYbYL5R72b7qGRdb9QAAvdxOJnCvEn5kaa+JVwANk+V4 LZQQ== 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 i10si5880515ede.101.2019.10.19.03.01.55; Sat, 19 Oct 2019 03:02:18 -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 S1725810AbfJSKBs (ORCPT + 99 others); Sat, 19 Oct 2019 06:01:48 -0400 Received: from Galois.linutronix.de ([193.142.43.55]:59086 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725283AbfJSKBs (ORCPT ); Sat, 19 Oct 2019 06:01:48 -0400 Received: from [5.158.153.52] (helo=nanos.tec.linutronix.de) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1iLlYH-0004Fy-IZ; Sat, 19 Oct 2019 12:01:37 +0200 Date: Sat, 19 Oct 2019 12:01:32 +0200 (CEST) From: Thomas Gleixner To: Huacai Chen cc: Andy Lutomirski , Vincenzo Frascino , LKML , stable , Arnd Bergmann , Paul Burton , "open list:MIPS" , linux-arm-kernel Subject: Re: [PATCH] lib/vdso: Use __arch_use_vsyscall() to indicate fallback In-Reply-To: Message-ID: References: <1571367619-13573-1-git-send-email-chenhc@lemote.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 19 Oct 2019, Huacai Chen wrote: > 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(). __arch_use_vsyscall() is a pointless exercise TBH. The VDSO data should be updated unconditionally so all the trivial interfaces like time() and getres() just work independently of the functions which depend on the underlying clocksource. This functions have a fallback operation already: Let __arch_get_hw_counter() return U64_MAX and the syscall fallback is invoked. __arch_use_vsyscall() should just be removed. Thanks, tglx