From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752289AbcAFRd3 (ORCPT ); Wed, 6 Jan 2016 12:33:29 -0500 Received: from mail-yk0-f174.google.com ([209.85.160.174]:33650 "EHLO mail-yk0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751809AbcAFRd2 (ORCPT ); Wed, 6 Jan 2016 12:33:28 -0500 MIME-Version: 1.0 In-Reply-To: References: <1452085234-10667-1-git-send-email-prarit@redhat.com> <1452085234-10667-2-git-send-email-prarit@redhat.com> Date: Wed, 6 Jan 2016 09:33:27 -0800 Message-ID: Subject: Re: [PATCH 1/2] kernel, timekeeping, add trylock option to ktime_get_with_offset() From: John Stultz To: Prarit Bhargava Cc: lkml , Thomas Gleixner , Ingo Molnar , Xunlei Pang , Peter Zijlstra , Baolin Wang , Arnd Bergmann Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 6, 2016 at 9:28 AM, John Stultz wrote: > On Wed, Jan 6, 2016 at 5:00 AM, Prarit Bhargava wrote: >> -ktime_t ktime_get_with_offset(enum tk_offsets offs) >> +ktime_t ktime_get_with_offset(enum tk_offsets offs, int trylock) >> { >> struct timekeeper *tk = &tk_core.timekeeper; >> unsigned int seq; >> ktime_t base, *offset = offsets[offs]; >> s64 nsecs; >> + unsigned long flags = 0; >> + >> + if (unlikely(!timekeeping_initialized)) >> + return ktime_set(0, 0); >> >> WARN_ON(timekeeping_suspended); >> >> + if (trylock && !raw_spin_trylock_irqsave(&timekeeper_lock, flags)) >> + return ktime_set(KTIME_MAX, 0); > > Wait.. this doesn't make sense. The timekeeper lock is only for reading. Only for writing.. sorry.. still drinking my coffee. > What I was suggesting to you off line is to have something that avoids > spinning on the seqcounter should if a bug occurs and we IPI all the > cpus, that we don't deadlock or block any printk messages. And more clearly here, if a cpu takes a write on the seqcounter in update_wall_time() and at that point another cpu hits a bug, and IPIs the cpus, the system would deadlock. That's really what I want to avoid. thanks -john