Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp6268823imu; Wed, 30 Jan 2019 11:41:33 -0800 (PST) X-Google-Smtp-Source: ALg8bN7iBj1Teqvx64QdmiZfr/UVp7FqZ8bU0Hhu2i1HEf55JWpweIwBcxiqfu8ctwLbVaxw9o2K X-Received: by 2002:a17:902:6b49:: with SMTP id g9mr31131041plt.98.1548877293458; Wed, 30 Jan 2019 11:41:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548877293; cv=none; d=google.com; s=arc-20160816; b=u8Jq6OX4hFc/XHE5bBfqPZNn8VYL/44XOKb0bxER76F1qHImb286cRZrskPY431R5O UFnEWGgqCOK8Z0U5YCheybbPpDfiXLCCDB+ABhvLEZXSjYU7t3PvoN2JppLmGWfC6zbG 72ZOH6EkP+zi4NqCco7n01UKhqmdambKeLqhN/W9S3Fq23GFhdLquomeTcynUZgAFZu+ 7qwQXz8gAVDSGJzTvM/g3nGKBvsBi7SFd9LXY/iGLk6VJYm/oMISvZuPEqAFsW0Rfi2Y UBgHB6ofzec/VOD/JxYHCN2zBtkIVU/Ktfw26D16L0eMiLZk7r6YLCj9SAWLciJNGlvF 61Vg== 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; bh=AYq0aGAbSP4ucXDByFbBCmLyl1ao2mKVwReHwoRCNAA=; b=ztITBnRfhQ3NgIsQ+yglxHcv3mqmadiUw7mlzltAIc2p91n04Jk4R3on8dJ2mg+7SK HDEnYJI9XDOJInQF36j6KYIP4m7j0WkyXeBOv1N5RmkBkDi3S4loB0EBgLM51GIVMI/E +XYHN0Tqn7jUDORxYTS527WhWTjEX8boKilCIlSl0g7P6haWX0k1jciXYwDSDJDRFnj6 sgtIjkklMsHOFINM1Wal+b/8M5kVjbzF7o8hPLCnl9EggOu87JeW7pDwDljyEciioT9B 39HReZTmMcUXxqg0Za46ViJb3PHUgib/2iicyi+vbDkI6SzMTI/WzbmgorfXbn3KMtZz 2Ajw== 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 c32si1016228plj.38.2019.01.30.11.41.17; Wed, 30 Jan 2019 11:41:33 -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; 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 S2387679AbfA3Tjb (ORCPT + 99 others); Wed, 30 Jan 2019 14:39:31 -0500 Received: from eddie.linux-mips.org ([148.251.95.138]:38660 "EHLO cvs.linux-mips.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387587AbfA3Tjb (ORCPT ); Wed, 30 Jan 2019 14:39:31 -0500 Received: (from localhost user: 'ladis' uid#1021 fake: STDIN (ladis@eddie.linux-mips.org)) by eddie.linux-mips.org id S23992819AbfA3Tj05RT5K (ORCPT + 3 others); Wed, 30 Jan 2019 20:39:26 +0100 Date: Wed, 30 Jan 2019 20:39:25 +0100 From: Ladislav Michl To: Vincent Guittot Cc: "Rafael J. Wysocki" , Linux PM , Linux Kernel Mailing List , Linux ARM , Linux OMAP Mailing List , "Rafael J. Wysocki" , Ulf Hansson , Biju Das , Geert Uytterhoeven , Linux-Renesas Subject: Re: [PATCH v2 ] PM-runtime: fix deadlock with ktime Message-ID: <20190130193925.GA11090@lenoch> References: <1548846984-2044-1-git-send-email-vincent.guittot@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 30, 2019 at 02:18:49PM +0100, Vincent Guittot wrote: > On Wed, 30 Jan 2019 at 14:06, Rafael J. Wysocki wrote: > > > > On Wed, Jan 30, 2019 at 12:16 PM Vincent Guittot > > wrote: > > > > > > A deadlock has been seen when swicthing clocksources which use PM runtime. > > > The call path is: > > > change_clocksource > > > ... > > > write_seqcount_begin > > > ... > > > timekeeping_update > > > ... > > > sh_cmt_clocksource_enable > > > ... > > > rpm_resume > > > pm_runtime_mark_last_busy > > > ktime_get > > > do > > > read_seqcount_begin > > > while read_seqcount_retry > > > .... > > > write_seqcount_end > > > > > > Although we should be safe because we haven't yet changed the clocksource > > > at that time, we can't because of seqcount protection. > > > > > > Use ktime_get_mono_fast_ns() instead which is lock safe for such case > > > > > > With ktime_get_mono_fast_ns, the timestamp is not guaranteed to be > > > monotonic across an update and as a result can goes backward. According to > > > update_fast_timekeeper() description: "In the worst case, this can > > > result is a slightly wrong timestamp (a few nanoseconds)". For > > > PM runtime autosuspend, this means only that the suspend decision can > > > be slightly sub optimal. > > > > > > Fixes: 8234f6734c5d ("PM-runtime: Switch autosuspend over to using hrtimers") > > > Reported-by: Biju Das > > > Signed-off-by: Vincent Guittot > > > > I've queued this one up as a fix for 5.0, but unfortunately it clashes > > with the patch from Ladislav Michl at > > https://patchwork.kernel.org/patch/10755477/ which has been dropped > > now. > > Thanks for adding Ladislav in this thread. > I'm sorry I forgot to add him in the loop. > > > > > Can you or Ladislav please rebase that patch on top of this one and repost? > > Ladislav, > > Let me know if you prefer to rebase and repost your patch of if you > want me to do. I'll rebase it on top of Rafael's bleeding-edge branch. Best regards, ladis > Regards, > Vincent > > > > > > --- > > > > > > - v2: Updated commit message to explain the impact of using > > > ktime_get_mono_fast_ns() > > > > > > drivers/base/power/runtime.c | 10 +++++----- > > > include/linux/pm_runtime.h | 2 +- > > > 2 files changed, 6 insertions(+), 6 deletions(-) > > > > > > diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c > > > index 457be03..708a13f 100644 > > > --- a/drivers/base/power/runtime.c > > > +++ b/drivers/base/power/runtime.c > > > @@ -130,7 +130,7 @@ u64 pm_runtime_autosuspend_expiration(struct device *dev) > > > { > > > int autosuspend_delay; > > > u64 last_busy, expires = 0; > > > - u64 now = ktime_to_ns(ktime_get()); > > > + u64 now = ktime_get_mono_fast_ns(); > > > > > > if (!dev->power.use_autosuspend) > > > goto out; > > > @@ -909,7 +909,7 @@ static enum hrtimer_restart pm_suspend_timer_fn(struct hrtimer *timer) > > > * If 'expires' is after the current time, we've been called > > > * too early. > > > */ > > > - if (expires > 0 && expires < ktime_to_ns(ktime_get())) { > > > + if (expires > 0 && expires < ktime_get_mono_fast_ns()) { > > > dev->power.timer_expires = 0; > > > rpm_suspend(dev, dev->power.timer_autosuspends ? > > > (RPM_ASYNC | RPM_AUTO) : RPM_ASYNC); > > > @@ -928,7 +928,7 @@ static enum hrtimer_restart pm_suspend_timer_fn(struct hrtimer *timer) > > > int pm_schedule_suspend(struct device *dev, unsigned int delay) > > > { > > > unsigned long flags; > > > - ktime_t expires; > > > + u64 expires; > > > int retval; > > > > > > spin_lock_irqsave(&dev->power.lock, flags); > > > @@ -945,8 +945,8 @@ int pm_schedule_suspend(struct device *dev, unsigned int delay) > > > /* Other scheduled or pending requests need to be canceled. */ > > > pm_runtime_cancel_pending(dev); > > > > > > - expires = ktime_add(ktime_get(), ms_to_ktime(delay)); > > > - dev->power.timer_expires = ktime_to_ns(expires); > > > + expires = ktime_get_mono_fast_ns() + (u64)delay * NSEC_PER_MSEC); > > > + dev->power.timer_expires = expires; > > > dev->power.timer_autosuspends = 0; > > > hrtimer_start(&dev->power.suspend_timer, expires, HRTIMER_MODE_ABS); > > > > > > diff --git a/include/linux/pm_runtime.h b/include/linux/pm_runtime.h > > > index 54af4ee..fed5be7 100644 > > > --- a/include/linux/pm_runtime.h > > > +++ b/include/linux/pm_runtime.h > > > @@ -105,7 +105,7 @@ static inline bool pm_runtime_callbacks_present(struct device *dev) > > > > > > static inline void pm_runtime_mark_last_busy(struct device *dev) > > > { > > > - WRITE_ONCE(dev->power.last_busy, ktime_to_ns(ktime_get())); > > > + WRITE_ONCE(dev->power.last_busy, ktime_get_mono_fast_ns()); > > > } > > > > > > static inline bool pm_runtime_is_irq_safe(struct device *dev) > > > -- > > > 2.7.4 > > >