Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp4224894imj; Tue, 12 Feb 2019 12:00:52 -0800 (PST) X-Google-Smtp-Source: AHgI3Ia1E2tglCBIk8ViUt4ndOT+8ykZxlzPWx2+9NnKJtYYVBCLF/Lf/GVVuI0qNzrgaLPhmGXr X-Received: by 2002:a17:902:4025:: with SMTP id b34mr5717719pld.181.1550001652066; Tue, 12 Feb 2019 12:00:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550001652; cv=none; d=google.com; s=arc-20160816; b=V4XsbsQB1l1DFbocIIYJxbJLRIn/UYOEFB4/bWB85jsvf4OCJjsUODIiiy2nDBwpT1 s1YrH9g9JRoD+fdIA0E1cQ5tV29HAYZdloYt/Ct9BTMMWI2eHkHoYkQM4jIjKAc/WUuo Je6PGp3QQCUTF8pNVKaRBuLTah6vRwBkWCPxw3cHhM1cXrj4E84AD6BJGCpmTKIRTrMM OlEIvUhKbO1IujuT18MnodXsWsy2H9zvElY0CwdR6eOtkb9CJSt/Nh91vREOESvem39m OqxmMIn9LSuOYsKZOasLr5/R/B0O9vjsa6pdoddUr7y7j9Ny4oARfRiFl9Kgo+dUslP4 6UMA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version; bh=AdMl9D1EQubWNGa4FwxZw9A50X7SiJSRx6uxLDxexyM=; b=xAsIyADnGARPQEOrrn8LWCGHQHMfqQE3+xVIKZwTCG1cVmbYmTNPDHpNMwjLTGYOIH BHway1gZWJZh7jahZC8HqxyuZCmkjmTVclBmcvtEasGt/7eCiSshJJ2DanVp8W8rqeK3 flPp4G9wzp3SX3IWUTzHulf19RLB33JZS9amLSFtjox+aV3rWKMVDAUrICRBgbxNSAtf bMX93EPV2miZRCj61N0gdNzYlz4c/EZyiV2ChUuIyEzTdNBKI9YhtLXSv/QaVq8DEizw F4PIC9QsHPJCdZVfwI7FFNPJrW71+3Yt3XdfUW2v34XtCtIRhrFKUqoAEKF0nJZ5cQgu gVlA== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p1si8441066pgg.306.2019.02.12.12.00.35; Tue, 12 Feb 2019 12:00:52 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731385AbfBLTFd (ORCPT + 99 others); Tue, 12 Feb 2019 14:05:33 -0500 Received: from mail-ot1-f67.google.com ([209.85.210.67]:46939 "EHLO mail-ot1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727977AbfBLTFd (ORCPT ); Tue, 12 Feb 2019 14:05:33 -0500 Received: by mail-ot1-f67.google.com with SMTP id w25so6178211otm.13; Tue, 12 Feb 2019 11:05:32 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AdMl9D1EQubWNGa4FwxZw9A50X7SiJSRx6uxLDxexyM=; b=Q41QbnEFIDyGJc9xWysvjOh5YyvshInkb/Mpp3G5qtY4vze6HceXSvvcK1grXKQQbh HZb3YhcxaLT3T8ZCCJeLefErBux/OO7eFHaMFn5O4QCksmqPpScTgVVpphV8IZti1Jhs iHplIp2l/gCWoCghgVg8NQBVN/JOZvXra6eFDrc3bzzlO51ubv7bDOkpfNYit34HlMNQ gDZydMscfAGOrYC7/tFzyX2fG5zstEGNTzTak1COnx72JekYIrpZpbNG7N1dilZ2bKKz 3YqEp5xrxSolwmC98uO/oLKdzQzbbQb3BhomZnCd0L8qrFhVZsPBjRLP5mt2bwryn9Yo zgLQ== X-Gm-Message-State: AHQUAuZnQf/1Y/hFiRaxiJNeWbTa2Cp92Libka2bAq9Jo4OzL3Zzfcqh /5XrkIz1i587G0+1Q/J6Ifsq7Q9YB0KTbs23Hsk= X-Received: by 2002:a9d:5a09:: with SMTP id v9mr3644755oth.244.1549998332374; Tue, 12 Feb 2019 11:05:32 -0800 (PST) MIME-Version: 1.0 References: <5510642.nRbR3bcduN@aspire.rjw.lan> <1670239.00ZbddH1IV@aspire.rjw.lan> In-Reply-To: From: "Rafael J. Wysocki" Date: Tue, 12 Feb 2019 20:05:21 +0100 Message-ID: Subject: Re: [PATCH 1/2] PM-runtime: Fix __pm_runtime_set_status() race with runtime resume To: Ulf Hansson Cc: "Rafael J. Wysocki" , "Rafael J. Wysocki" , Greg Kroah-Hartman , LKML , Linux PM , Daniel Vetter , Lukas Wunner , Andrzej Hajda , Russell King - ARM Linux , Lucas Stach , Linus Walleij , Thierry Reding , Laurent Pinchart , Marek Szyprowski Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 12, 2019 at 7:28 PM Ulf Hansson wrote: > > On Tue, 12 Feb 2019 at 17:28, Rafael J. Wysocki wrote: > > > > On Tue, Feb 12, 2019 at 5:18 PM Ulf Hansson wrote: > > > > > > On Tue, 12 Feb 2019 at 13:10, Rafael J. Wysocki wrote: > > > > > > > > From: Rafael J. Wysocki > > > > > > > > Commit 4080ab083000 ("PM-runtime: Take suppliers into account in > > > > __pm_runtime_set_status()") introduced a race condition that may > > > > trigger if __pm_runtime_set_status() is used incorrectly (that is, > > > > if it is called when PM-runtime is enabled for the target device > > > > and working). > > > > > > > > In that case, if the original PM-runtime status of the device is > > > > RPM_SUSPENDED, a runtime resume of the device may occur after > > > > __pm_runtime_set_status() has dropped its power.lock spinlock > > > > and before deactivating its suppliers, so the suppliers may be > > > > deactivated while the device is PM-runtime-active which may lead > > > > to functional issues. > > > > > > > > To avoid that, modify __pm_runtime_set_status() to check whether > > > > or not PM-runtime is enabled for the device before activating its > > > > suppliers (if the new status is RPM_ACTIVE) and either return an > > > > error if that's the case or increment the device's disable_depth > > > > counter to prevent PM-runtime from being enabled for it while > > > > the remaining part of the function is running (disable_depth is > > > > then decremented on the way out). > > > > > > > > Fixes: 4080ab083000 ("PM-runtime: Take suppliers into account in __pm_runtime_set_status()") > > > > Signed-off-by: Rafael J. Wysocki > > > > --- > > > > drivers/base/power/runtime.c | 24 ++++++++++++++++++------ > > > > 1 file changed, 18 insertions(+), 6 deletions(-) > > > > > > > > Index: linux-pm/drivers/base/power/runtime.c > > > > =================================================================== > > > > --- linux-pm.orig/drivers/base/power/runtime.c > > > > +++ linux-pm/drivers/base/power/runtime.c > > > > @@ -1129,6 +1129,22 @@ int __pm_runtime_set_status(struct devic > > > > if (status != RPM_ACTIVE && status != RPM_SUSPENDED) > > > > return -EINVAL; > > > > > > > > + spin_lock_irq(&dev->power.lock); > > > > + > > > > + /* > > > > + * Prevent PM-runtime from being enabled for the device or return an > > > > + * error if it is enabled already and working. > > > > + */ > > > > + if (dev->power.runtime_error || dev->power.disable_depth) > > > > + dev->power.disable_depth++; > > > > + else > > > > + error = -EAGAIN; > > > > + > > > > + spin_unlock_irq(&dev->power.lock); > > > > + > > > > + if (error) > > > > + return error; > > > > + > > > > /* > > > > * If the new status is RPM_ACTIVE, the suppliers can be activated > > > > * upfront regardless of the current status, because next time > > > > @@ -1147,12 +1163,6 @@ int __pm_runtime_set_status(struct devic > > > > > > > > spin_lock_irq(&dev->power.lock); > > > > > > > > - if (!dev->power.runtime_error && !dev->power.disable_depth) { > > > > - status = dev->power.runtime_status; > > > > - error = -EAGAIN; > > > > - goto out; > > > > - } > > > > - > > > > if (dev->power.runtime_status == status || !parent) > > > > goto out_set; > > > > > > > > @@ -1205,6 +1215,8 @@ int __pm_runtime_set_status(struct devic > > > > device_links_read_unlock(idx); > > > > } > > > > > > > > + pm_runtime_enable(dev); > > > > > > pm_runtime_enable() uses spin_lock_irqsave(), rather than > > > spin_lock_irq() - is there a reason to why you want to allow that > > > here, but not earlier in the function? > > > > Device links locking cannot be used in interrupt context. > > I get that, but thanks for clarifying. > > However, then why did you convert __pm_runtime_set_status() from using > spin_lock_irqsave() to spin_lock_irq() in commit "PM-runtime: Take > suppliers into account in __pm_runtime_set_status()"? > > As far as I can tell, the spin_lock is not being held while we operate > on the device links anyway. Or is this just to give the caller an > indication what kind of context the function can be called from? The latter plus getting rid of saving/restoring the flags which isn't necessary.