Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp2313805pxa; Mon, 24 Aug 2020 10:37:52 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyN3QgdWyB+KusR2RynvgFDkCU9bbchxQ6hTKioY5HNFxXQgsz9baaNj7uHdjdi+LJc7U5a X-Received: by 2002:a17:906:b157:: with SMTP id bt23mr6988958ejb.354.1598290671771; Mon, 24 Aug 2020 10:37:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1598290671; cv=none; d=google.com; s=arc-20160816; b=q1/ULa/SDP7R4kjqsPYYdCuKCeO1xYAKjc887QJ51j/mJUKcFpjym8x3w0lhJB70ek QlRYND9Pe4PHS/KfcL0tJ5fIcWcDIKlhDtPHzauzGJf12usSTr0CxSkB9VRGwLCtRHBw /PCT6cy8uqt9l+wSZe1efevIVQGCADyh/OFRtw1IcJMvUL4OtOKBf7D6LUKBE6UTZXIc WEmaZA3qHSxK4avX4ghM4ECoycOKYHQC+HnwVUrcBTaZgYF9eD/SA2uAhhOZPXQ7Gn0d IN+LUYZDfxX8M4E7GgEljjRjqpSzIdbGHX8tMrTbB1K/fmKCJsMWMJXQoOGbDzLb14WC RDGg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=P+o29H8sAPlEshepWEz+sbcf87kyVbkfYUnxVhSiBgY=; b=s3i6Rj5NUe/YJND/fxNnq4Xbpa0sTeRtaLHQ08QEuvdhbGsNtQOwqTYXsD4hwyI87O PhEtVdVdWvDz8bZZEE/qFdwdtsDvwxoPzxPNY98PS1rY9QmoYxf87tUIaBdgECREcPa3 2sHvk6biLCveZ3tNRB0OR3fmpDqgiZU4qyEsDIiTbqnzUc0Z/fseUl/7Ncfxyaa0mzFZ +9vbMsg87aRlxPXgOU8ykzPty219tugLdBlsYd/D7SQ5/Clw+MFv9UP1CYwxavfD0Zf3 hSec/FhbBI3rTWl1Vjx4PTGsXEao/l1oj2WySC8CjsxfAcn8g4RqdC0Njq31rLrqB+nA Pp7w== 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 k22si6821237edx.491.2020.08.24.10.37.28; Mon, 24 Aug 2020 10:37:51 -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 S1728521AbgHXRfl (ORCPT + 99 others); Mon, 24 Aug 2020 13:35:41 -0400 Received: from cloudserver094114.home.pl ([79.96.170.134]:55850 "EHLO cloudserver094114.home.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726630AbgHXRff (ORCPT ); Mon, 24 Aug 2020 13:35:35 -0400 Received: from 89-64-88-199.dynamic.chello.pl (89.64.88.199) (HELO kreacher.localnet) by serwer1319399.home.pl (79.96.170.134) with SMTP (IdeaSmtpServer 0.83.459) id c842b0c3f2076e9b; Mon, 24 Aug 2020 19:35:32 +0200 From: "Rafael J. Wysocki" To: Linux PM Cc: LKML , Linux ACPI , Greg Kroah-Hartman , "Rafael J. Wysocki" , Mika Westerberg , Alan Stern Subject: [PATCH v2] PM: sleep: core: Fix the handling of pending runtime resume requests Date: Mon, 24 Aug 2020 19:35:31 +0200 Message-ID: <1954100.8R8RjBe1nF@kreacher> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit 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 From: Rafael J. Wysocki It has been reported that system-wide suspend may be aborted in the absence of any wakeup events due to unforseen interactions of it with the runtume PM framework. One failing scenario is when there are multiple devices sharing an ACPI power resource and runtime-resume needs to be carried out for one of them during system-wide suspend (for example, because it needs to be reconfigured before the whole system goes to sleep). In that case, the runtime-resume of that device involves turning the ACPI power resource "on" which in turn causes runtime-resume requests to be queued up for all of the other devices sharing it. Those requests go to the runtime PM workqueue which is frozen during system-wide suspend, so they are not actually taken care of until the resume of the whole system, but the pm_runtime_barrier() call in __device_suspend() sees them and triggers system wakeup events for them which then cause the system-wide suspend to be aborted if wakeup source objects are in active use. Of course, the logic that leads to triggering those wakeup events is questionable in the first place, because clearly there are cases in which a pending runtime resume request for a device is not connected to any real wakeup events in any way (like the one above). Moreover, it is racy, because the device may be resuming already by the time the pm_runtime_barrier() runs and so if the driver doesn't take care of signaling the wakeup event as appropriate, it will be lost. However, if the driver does take care of that, the extra pm_wakeup_event() call in the core is redundant. Accordingly, drop the conditional pm_wakeup_event() call fron __device_suspend() and make the latter call pm_runtime_barrier() alone. Also modify the comment next to that call to reflect the new code and extend it to mention the need to avoid unwanted interactions between runtime PM and system-wide device suspend callbacks. Fixes: 1e2ef05bb8cf8 ("PM: Limit race conditions between runtime PM and system sleep (v2)") Reported-by: Mika Westerberg Signed-off-by: Rafael J. Wysocki --- -> v2: * Do not call pm_runtime_resume() if pm_runtime_barrier() returns 1, because the device have been resumed by it already. * Extend the comment next to the pm_runtime_barrier() call. * Update the changelog in accordance with the above. --- drivers/base/power/main.c | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) Index: linux-pm/drivers/base/power/main.c =================================================================== --- linux-pm.orig/drivers/base/power/main.c +++ linux-pm/drivers/base/power/main.c @@ -1606,13 +1606,17 @@ static int __device_suspend(struct devic } /* - * If a device configured to wake up the system from sleep states - * has been suspended at run time and there's a resume request pending - * for it, this is equivalent to the device signaling wakeup, so the - * system suspend operation should be aborted. + * Wait for possible runtime PM transitions of the device in progress + * to complete and if there's a runtime resume request pending for it, + * resume it before proceeding with invoking the system-wide suspend + * callbacks for it. + * + * If the system-wide suspend callbacks below change the configuration + * of the device, they must disable runtime PM for it or otherwise + * ensure that its runtime-resume callbacks will not be confused by that + * change in case they are invoked going forward. */ - if (pm_runtime_barrier(dev) && device_may_wakeup(dev)) - pm_wakeup_event(dev, 0); + pm_runtime_barrier(dev); if (pm_wakeup_pending()) { dev->power.direct_complete = false;