Received: by 2002:a05:6a10:8395:0:0:0:0 with SMTP id n21csp615079pxh; Tue, 9 Nov 2021 16:13:11 -0800 (PST) X-Google-Smtp-Source: ABdhPJxpUuJiRr0HtR0lMhHlrRc20SGyHC59QKmdy6n/Q0DKs1SpW77f8TyMzFNWqxppdCJSS4ZB X-Received: by 2002:a05:6e02:20ea:: with SMTP id q10mr8190020ilv.10.1636503191139; Tue, 09 Nov 2021 16:13:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1636503191; cv=none; d=google.com; s=arc-20160816; b=H07cSOB/Kp5042U876ixk01rA3QtwXr6yAcemq0VAHr7hBFDCVdr3Dcmhdpt24CRYN pjoHBA+TKt8FO7T4lysiTMBMJxoF4//c4bz2q2ag4aCwbAi03SOKfclwGwpy9o2o5fCR iaQjFJQNhQZD1UtOZtXqaUnHIuz7X0DyV0yLfb6q6wdI7mxRBp5IONMQ6/zkUIdSEG3O 2SUP2S/chLftRCqUInTG4XYLxk+g1pklA9XadJQAAy+gzZV8ODtb0b0W6R0lpB9P3CF9 8BJGpT5IudOLB443t0HCU/xwpy1Lt2ykR2osZxWo//JTjemyd0JSneHdawVb5I9KgOs2 L0cA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version; bh=nAduBtZHWBwalAr13uvE799l0ekGLBq3HPaw2wFvmWk=; b=iNvC9BtoQsGFf80zwiLHzvpN9DqDDxAvXLWx/05YXfPbCFcpsTGyR0nZ7lFL2ulzYN IKUItJw2bcvNIiATioNtzA7rqfZON/0si9LMEsrp74ZfrOUEJmqUtk+i6jJdQWqU/Ze/ ScjWYcEh6ZM2go01iWZPBa762iYFfFTUUFaRbVWpszjbsjjosG0jeY09liLxJrOOVJxz hGBdXjWlXh+zyXbmZg9x9YhqBPjKkIj9H+X+TmIjtawS2nj764eI9Y1xNxcFIQmjQmmt oqMLzmm6I1oHwgRWJ55KM/3HmPr7bLoV4v5S7rIWG2ig1DtI3Ng4m01xssVhEWL8buE9 bI1Q== 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id z4si7591521jat.116.2021.11.09.16.12.59; Tue, 09 Nov 2021 16:13:11 -0800 (PST) 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242780AbhKISzG convert rfc822-to-8bit (ORCPT + 97 others); Tue, 9 Nov 2021 13:55:06 -0500 Received: from mail-oi1-f177.google.com ([209.85.167.177]:45829 "EHLO mail-oi1-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242769AbhKISzF (ORCPT ); Tue, 9 Nov 2021 13:55:05 -0500 Received: by mail-oi1-f177.google.com with SMTP id u2so351125oiu.12; Tue, 09 Nov 2021 10:52:19 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=bFenRzuO5dINHJKhrBAdIcXc5IDUu3Mc99we7/TSBKc=; b=yP5FigzMPITjqF6cDkesqwyqRMADf4Mt3Cb+77VngOiqOdq6Jx3akb/eSofujhL2Tb WmW/hrmeg3eHNKqL1oYElqzkKrZXqKr9mxOmr5vVMxygCCV7sZU5hDkpHIfovOtSq5wn KIGorEjGBRqegH35l0AONt6Q/T+lBZoLRpxDivnw87MMY3vOyfUVybAuhQSP5BhXeRlt MQvtMXDnymL6+yJHjVozU3QuZrkKMLKs5ibfxcF0OyLMTlqCQgisl589mk63nMt4bQ7F vyCny7PvEmlOyR1rvUiPnS+p3I+EBiLLO6vAzuK7hY8Yj3A5+p5oUw1bI4VK0rf5dN8b i48g== X-Gm-Message-State: AOAM531+CFei7TjYZ8PQngtFCCMaDwmzbb+1TJ9+SKJMZ9B9i59cQgZK Lp79yAT0+Vbn4SXwulePCCYP7MqkOTDn5n4YQF0= X-Received: by 2002:a05:6808:14d0:: with SMTP id f16mr7728814oiw.51.1636483939099; Tue, 09 Nov 2021 10:52:19 -0800 (PST) MIME-Version: 1.0 References: <20211109181224.GA1162053@bhelgaas> In-Reply-To: <20211109181224.GA1162053@bhelgaas> From: "Rafael J. Wysocki" Date: Tue, 9 Nov 2021 19:52:08 +0100 Message-ID: Subject: Re: [PATCH] pci: Don't call resume callback for nearly bound devices To: Bjorn Helgaas Cc: "Rafael J. Wysocki" , =?UTF-8?Q?Uwe_Kleine=2DK=C3=B6nig?= , =?UTF-8?B?Um9iZXJ0IMWad2nEmWNraQ==?= , linux-i2c , Bjorn Helgaas , Linux PCI , Linux PM , Linux Kernel Mailing List , Greg Kroah-Hartman Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 9, 2021 at 7:12 PM Bjorn Helgaas wrote: > > On Tue, Nov 09, 2021 at 06:18:18PM +0100, Rafael J. Wysocki wrote: > > On Tue, Nov 9, 2021 at 7:59 AM Uwe Kleine-König > > wrote: > > > On Mon, Nov 08, 2021 at 08:56:19PM -0600, Bjorn Helgaas wrote: > > > > [+cc Greg: new device_is_bound() use] > > > > > > ack, that's what I would have suggested now, too. > > > > > > > On Mon, Nov 08, 2021 at 10:22:26PM +0100, Uwe Kleine-König wrote: > > > > > pci_pm_runtime_resume() exits early when the device to resume isn't > > > > > bound yet: > > > > > > > > > > if (!to_pci_driver(dev->driver)) > > > > > return 0; > > > > > > > > > > This however isn't true when the device currently probes and > > > > > local_pci_probe() calls pm_runtime_get_sync() because then the driver > > > > > core already setup dev->driver. As a result the driver's resume callback > > > > > is called before the driver's probe function is called and so more often > > > > > than not required driver data isn't setup yet. > > > > > > > > > > So replace the check for the device being unbound by a check that only > > > > > becomes true after .probe() succeeded. > > > > > > > > I like the fact that this patch is short and simple. > > > > > > > > But there are 30+ users of to_pci_driver(). This patch asserts that > > > > *one* of them, pci_pm_runtime_resume(), is special and needs to test > > > > device_is_bound() instead of using to_pci_driver(). > > > > > > Maybe for the other locations using device_is_bound(&pdev->dev) instead > > > of to_pci_driver(pdev) != NULL would be nice, too? > > > > > > I have another doubt: device_is_bound() should (according to its > > > kernel-doc) be called with the device lock held. For the call stack that > > > is (maybe) fixed here, the lock is held (by __device_attach). We > > > probably should check if the lock is also held for the other calls of > > > pci_pm_runtime_resume(). > > > > > > Hmm, the device lock is a mutex, the pm functions might be called in > > > atomic context, right? > > > > > > > It's special because the current PM implementation calls it via > > > > pm_runtime_get_sync() before the driver's .probe() method. That > > > > connection is a little bit obscure and fragile. What if the PM > > > > implementation changes? > > > > > > Maybe a saver bet would be to not use pm_runtime_get_sync() in > > > local_pci_probe()? > > > > Yes, in principle it might be replaced with pm_runtime_get_noresume(). > > > > In theory, that may be problematic if a device is put into a low-power > > state on remove and then the driver is bound again to it. > > > > > I wonder if the same problem exists on remove, i.e. pci_device_remove() > > > calls pm_runtime_put_sync() after the driver's .remove() callback was > > > called. > > > > If it is called after ->remove() and before clearing the device's > > driver pointer, then yes. > > Yes, that is the case: > > pci_device_remove > if (drv->remove) { > pm_runtime_get_sync > drv->remove() # <-- driver ->remove() method > pm_runtime_put_noidle > } > ... > pm_runtime_put_sync # <-- after ->remove() > > So pm_runtime_put_sync() is called after drv->remove(), and it may > call drv->pm->runtime_idle(). I think the driver may not expect this. > > > If this is turned into pm_runtime_put_noidle(), all should work. > > pci_device_remove() already calls pm_runtime_put_noidle() immediately > after calling the driver ->remove() method. > > Are you saying we should do this, which means pci_device_remove() > would call pm_runtime_put_noidle() twice? Well, they are both needed to keep the PM-runtime reference counting in balance. This still has an issue, though, because user space would be able to trigger a runtime suspend via sysfs after we've dropped the last reference to the device in pci_device_remove(). So instead, we can drop the pm_runtime_get_sync() and pm_runtime_put_sync() from local_pci_probe() and pci_device_remove(), respectively, and add pm_runtine_get_noresume() to pci_pm_init(), which will prevent PM-runtime from touching the device until it has a driver that supports PM-runtime. We'll lose the theoretical ability to put unbound devices into D3 this way, but we learned some time ago that this isn't safe in all cases anyway. > diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c > index 1d98c974381c..79c1a920fdc8 100644 > --- a/drivers/pci/pci-driver.c > +++ b/drivers/pci/pci-driver.c > @@ -318,7 +318,7 @@ static long local_pci_probe(void *_ddi) > * count, in its probe routine and pm_runtime_get_noresume() in > * its remove routine. > */ > - pm_runtime_get_sync(dev); > + pm_runtime_get_noresume(dev); > rc = pci_drv->probe(pci_dev, ddi->id); > if (!rc) > return rc; > @@ -465,7 +465,7 @@ static void pci_device_remove(struct device *dev) > pci_iov_remove(pci_dev); > > /* Undo the runtime PM settings in local_pci_probe() */ > - pm_runtime_put_sync(dev); > + pm_runtime_put_noidle(dev); > > /* > * If the device is still on, set the power state as "unknown",