Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp2207740pxa; Mon, 24 Aug 2020 08:05:42 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxHJ/FWd5WSVU7XA3Lcd9VIRiu8g8kYUNex2+ESvU3kKCsnDhMf3HoHb2nWFWPp7kv0k0Ca X-Received: by 2002:aa7:d955:: with SMTP id l21mr5907374eds.343.1598281541965; Mon, 24 Aug 2020 08:05:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1598281541; cv=none; d=google.com; s=arc-20160816; b=w9/dMTC85AmV6kVeIA0XtdTiiitCLbNKdZEJOWYn7TeW6bYSgp1mji4XTqTroTwDIB 0lOnQNwuwXEuO2a2x9BG7+fEbFCaAR67hhVMJVI3Cdt1/SIZGDMLVzVNYL7pd5xd3+Zv lok5WFuv9XDNwafgZCxvF17VRLXoqT6XWl9pepnkgbVxSkZx7hDf/+JKg7La4lmsYWCV 9sf88CVZFkbZILoK9eCIhm6ttneHskgotK4r+LhJr7pHj6KD0vE1+TF5itgcWgBTpwPV ksT6Bw1kdM0gyJ06NaM3B/gFETE2nR3okuhJCVBFekVmHhI7zxhSisrepGi0w6Ee0I2G rLsA== 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=2QpIPeY9eRPTTGgG2RueO5QahpfKC55ngaRfdkMQBzM=; b=tTPF4HuwaUY/rW9fFJINqEoc6tpHMpAezg4j7KFWzKcHuKEZksGO0T+BrmSm49tgFL kbeoBCyQtsf6mgGKhgtA431pJkNhFZBdtzGWvAVNxYy0xkWlpGjVVg2E1v3M3k7bkX/S bhC2Uqi9PZytTUk77RluWoQ08brhKChLQIhTGDNLIosqAarPvUVAmfN659ef+D67tpIp ATfJAm7EKwm1HLkfw+yXHcEE84zq3aHmFnKRgX671pemv39lORXRE9c9DPlJGkfLs/GI jZWHbA/dk+M7v4Wf9sBhT2tTiZjr/krqrBCC9E7eWi9XSJjm1vKq/6ntLcGrATwMOcXi 5Dzg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y6si4815243edp.363.2020.08.24.08.05.16; Mon, 24 Aug 2020 08:05:41 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726225AbgHXPEb (ORCPT + 99 others); Mon, 24 Aug 2020 11:04:31 -0400 Received: from netrider.rowland.org ([192.131.102.5]:40933 "HELO netrider.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1725946AbgHXPEW (ORCPT ); Mon, 24 Aug 2020 11:04:22 -0400 Received: (qmail 332615 invoked by uid 1000); 24 Aug 2020 11:04:21 -0400 Date: Mon, 24 Aug 2020 11:04:21 -0400 From: Alan Stern To: "Rafael J. Wysocki" Cc: Linux PM , LKML , Linux ACPI , Greg Kroah-Hartman , "Rafael J. Wysocki" , Mika Westerberg Subject: Re: [PATCH] PM: sleep: core: Fix the handling of pending runtime resume requests Message-ID: <20200824150421.GD329866@rowland.harvard.edu> References: <7969920.MVx1BpXlEM@kreacher> <20200821193442.GA264863@rowland.harvard.edu> <4922509.6NPD9QEisq@kreacher> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4922509.6NPD9QEisq@kreacher> 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 Mon, Aug 24, 2020 at 03:36:36PM +0200, Rafael J. Wysocki wrote: > > Furthermore, by the logic used in this patch, the call to > > pm_wakeup_event() in the original code is also redundant: Any required > > wakeup event should have been generated when the runtime resume inside > > pm_runtime_barrer() was carried out. > > It should be redundant in the real wakeup event cases, but it may cause > spurious suspend aborts to occur when there are no real system wakeup > events. > > Actually, the original code is racy with respect to system wakeup events, > because it depends on the exact time when the runtime-resume starts. Namely, > if it manages to start before the freezing of pm_wq, the wakeup will be lost > unless the driver takes care of reporting it, which means that drivers really > need to do that anyway. And if they do that (which hopefully is the case), the > pm_wakeup_event() call in the core may be dropped. In other words, wakeup events are supposed to be reported at the time the wakeup request is first noticed, right? We don't want to wait until a resume or runtime_resume callback runs; thanks to this race the callback might not run at all if the event isn't reported first. Therefore the reasoning behind the original code appears to have been highly suspect. If there already was a queued runtime-resume request for the device and the device was wakeup-enabled, the wakeup event should _already_ have been reported at the time the request was queued. And we shouldn't rely on it being reported by the runtime-resume callback routine. > > This means that the code could be simplified to just: > > > > pm_runtime_barrier(dev); > > Yes, it could, so I'm going to re-spin the patch with this code simplification > and updated changelog. > > > Will this fix the reported bug? > > I think so. Okay, we'll see! Alan Stern