Received: by 10.223.176.46 with SMTP id f43csp724404wra; Fri, 26 Jan 2018 06:01:32 -0800 (PST) X-Google-Smtp-Source: AH8x224D0sKkpRTgL+u+FwL8L+i83p7jPhIGovX5Ap+t/Uys+sIrO+XzrN2b98jmp4oT6yOi+G0k X-Received: by 10.98.204.144 with SMTP id j16mr19489901pfk.101.1516975292249; Fri, 26 Jan 2018 06:01:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516975292; cv=none; d=google.com; s=arc-20160816; b=tp8Gimrug7f/6yUHEmr7W/dzKskhYKlFQbPOJgeqdhYxOHajGvsjCP1+tbJqTuanB4 /sDgjFbeAp3EHWGB7XahGZwR/DwGp5ndN6txfCTBAZVJU1xfAx7WveH0jiva1ZqrfF/D WL+5BkX5SO6BBH+mUKsGgWq6YorOJthscPjq1c/gWUf5xX5XYrO+uy9S31QpURHw1G/1 b67oXl+SBeu49wIQvelqhXqLzhFJukgEpWdusuP9+VeimJHVVxbQFO2GmL2PCS/uSCvJ kitEYArfjwFLJq2Ge+JEL5Co9mzmw2yn69wmZET6v5y5FBE21C756XYniUXhsNLzPxRs tq+g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=EmhBP0d/qhUgyN13PD5MPYlMhJahhcIdnvMjkVf3Psk=; b=Q83xHdYYXi1SVY+l7KJd9FMBpAXe6mXPG+sb8SNaKM2e5yQsllPdujmy8ueq2HWX03 csEJ2Amq9HnxXqfPppkOeAooYucxqfOwdF4/Rf+VEyYps6aBDOAe1FvnYZC7e0+IIZNE YvmSCO1BaOZTOlYaM+AmZIgOAgfPYVIMroHVivXMLKAYkBmAj31xYbnNWc7L72x+RfFJ HxJU4vMcC1b7eq0sU2QuMZA+llv4ROm8CUlymbhidT+mcS/Ya3UbKRgyKJUHjfaHiVk1 yt3cl/TatYaIw/qznqGFgHzWa/c/5zrHfntT8KKXVNBllsrr9rIKDHzMjXy6S14UaZhA e93w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=DOu5sN+i; 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=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h20si6379616pfh.395.2018.01.26.06.01.17; Fri, 26 Jan 2018 06:01:32 -0800 (PST) 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=@linaro.org header.s=google header.b=DOu5sN+i; 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=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752885AbeAZOAl (ORCPT + 99 others); Fri, 26 Jan 2018 09:00:41 -0500 Received: from mail-wm0-f66.google.com ([74.125.82.66]:54285 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752747AbeAZOAi (ORCPT ); Fri, 26 Jan 2018 09:00:38 -0500 Received: by mail-wm0-f66.google.com with SMTP id i186so1462580wmi.4 for ; Fri, 26 Jan 2018 06:00:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=EmhBP0d/qhUgyN13PD5MPYlMhJahhcIdnvMjkVf3Psk=; b=DOu5sN+ibZ4/B5r7HJFqIfmZaaYWzM/chvOoLLRh/YuenwIqcVhvroI6qa9Ee09cb/ KR6c29EAZUxf9Vdx7h6S6FmmdtHPXyY3bdjqOeDlp75xN8zoA0maj7DNvSYUl3+yh5E/ KAnsVgu1RBjofmhZpWhHQ1+JUh/vpkNu+dtWI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=EmhBP0d/qhUgyN13PD5MPYlMhJahhcIdnvMjkVf3Psk=; b=E2qJ+jxS/ER08vEZWjjiAKrzR5chd68/fsrmyeyjPUFksJb0KHnZacVVGf089rpuyP Ck/GbQkL0y5NQOwrA+uoSpoAK8BNxzK41e1W44rGJlHcoUraTJrc1dadDNsGy915QbYc MaK/GJmdnCKfyosmQPc2caZkA/lEM5IbIsPsRkdSEjM5sp1N2N+2GvbZmlCtEG/MQ7Ep Uvn2BT/rWsxTUYDjAaWZOLm2Begz1JLQbdly4ia1k2W3MKGo0TRVFdIA1fytEyaWeEGg iyHtjYcuHqbg6iu7nDsvMtJhN1Ml6z9ITGS0xY5Wmf0LTDbeghkLg1a4pDBTsX+k80yf ai/w== X-Gm-Message-State: AKwxytcPMP5k0VVLz6nDNLndckjEYXg5NMkmB/21g5TlRqdw6oRdSqkj 3tuONy0b9VAzg6w+dbWGTh/4rg== X-Received: by 10.28.108.4 with SMTP id h4mr10054371wmc.161.1516975236835; Fri, 26 Jan 2018 06:00:36 -0800 (PST) Received: from oak.lan (cpc141214-aztw34-2-0-cust773.18-1.cable.virginm.net. [86.9.19.6]) by smtp.gmail.com with ESMTPSA id q195sm4371602wmb.33.2018.01.26.06.00.35 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 26 Jan 2018 06:00:35 -0800 (PST) Date: Fri, 26 Jan 2018 14:00:33 +0000 From: Daniel Thompson To: Arnd Bergmann Cc: Baolin Wang , Jason Wessel , Ingo Molnar , Mark Brown , kgdb-bugreport@lists.sourceforge.net, Linux Kernel Mailing List Subject: Re: [PATCH] kdb: use ktime_get_seconds() instead of ktime_get_ts() Message-ID: <20180126140033.ix2n7j62k6iccmdh@oak.lan> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jan 26, 2018 at 10:21:58AM +0100, Arnd Bergmann wrote: > On Fri, Jan 26, 2018 at 4:03 AM, Baolin Wang wrote: > > The kdb code will print the monotonic time by ktime_get_ts(), but > > the ktime_get_ts() will be protected by a sequence lock, that will > > introduce one deadlock risk if the lock was already held in the > > context from which we entered the debugger. > > > > Since kdb is only interested in the second field, we can use the > > ktime_get_seconds() to get the monotonic time without a lock, > > moreover we can remove the 'struct timespec', which is not y2038 > > safe. > > > > Signed-off-by: Baolin Wang > > --- > > kernel/debug/kdb/kdb_main.c | 4 +--- > > 1 file changed, 1 insertion(+), 3 deletions(-) > > > > diff --git a/kernel/debug/kdb/kdb_main.c b/kernel/debug/kdb/kdb_main.c > > index 69e70f4..f0fc6f7 100644 > > --- a/kernel/debug/kdb/kdb_main.c > > +++ b/kernel/debug/kdb/kdb_main.c > > @@ -2486,10 +2486,8 @@ static int kdb_kill(int argc, const char **argv) > > */ > > static void kdb_sysinfo(struct sysinfo *val) > > { > > - struct timespec uptime; > > - ktime_get_ts(&uptime); > > memset(val, 0, sizeof(*val)); > > - val->uptime = uptime.tv_sec; > > + val->uptime = ktime_get_seconds(); > > val->loads[0] = avenrun[0]; > > val->loads[1] = avenrun[1]; > > val->loads[2] = avenrun[2]; > > Using ktime_get_seconds() avoids locking problems, but I wonder what > would happen if we trigger the 'WARN_ON(timekeeping_suspended)' > from kdb. Is that a problem? If it is, we have to use ktime_get_mono_fast_ns() > and div_u64() instead. Normally a WARN_ON() doesn't triggered a kgdb_breakpoint() so (apart from bugs) we can start executing the warning. Unfortunately kdb_trap_printk isn't set when we call ktime_get_seconds() so printing the warning isn't safe. If we had no choice of time function we could work around by enabling printk() trapping for the call but since ktime_get_mono_fast_ns() already exists its probably best just to use that. Daniel.