From patchwork Fri Apr 22 20:22:01 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Rafael Wysocki X-Patchwork-Id: 728021 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by demeter1.kernel.org (8.14.4/8.14.3) with ESMTP id p3MKGNUX032248 for ; Fri, 22 Apr 2011 20:21:59 GMT Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756357Ab1DVUV6 (ORCPT ); Fri, 22 Apr 2011 16:21:58 -0400 Received: from ogre.sisk.pl ([217.79.144.158]:45018 "EHLO ogre.sisk.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755181Ab1DVUV5 (ORCPT ); Fri, 22 Apr 2011 16:21:57 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by ogre.sisk.pl (Postfix) with ESMTP id 4A2B81ABDAC; Fri, 22 Apr 2011 22:20:43 +0200 (CEST) Received: from ogre.sisk.pl ([127.0.0.1]) by localhost (ogre.sisk.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06194-08; Fri, 22 Apr 2011 22:20:21 +0200 (CEST) Received: from ferrari.rjw.lan (220-bem-13.acn.waw.pl [82.210.184.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ogre.sisk.pl (Postfix) with ESMTP id 7308B1AC7C4; Fri, 22 Apr 2011 22:20:21 +0200 (CEST) From: "Rafael J. Wysocki" To: Alan Stern Subject: Re: [PATCH/RFC] MMC: remove unbalanced pm_runtime_suspend() Date: Fri, 22 Apr 2011 22:22:01 +0200 User-Agent: KMail/1.13.6 (Linux/2.6.39-rc4+; KDE/4.6.0; x86_64; ; ) Cc: Guennadi Liakhovetski , "Ohad Ben-Cohen" , linux-mmc@vger.kernel.org, Magnus Damm , Simon Horman , Linux PM mailing list References: In-Reply-To: MIME-Version: 1.0 Message-Id: <201104222222.01289.rjw@sisk.pl> X-Virus-Scanned: amavisd-new at ogre.sisk.pl using MkS_Vir for Linux Sender: linux-mmc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-mmc@vger.kernel.org X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.6 (demeter1.kernel.org [140.211.167.41]); Fri, 22 Apr 2011 20:22:04 +0000 (UTC) On Friday, April 22, 2011, Alan Stern wrote: > On Fri, 22 Apr 2011, Rafael J. Wysocki wrote: > > > > The subsystem should be smart enough to handle runtime PM requests while > > > the driver's remove callback is running. > > > > If we make such a rule, we may as well remove all of the runtime PM > > calls from __device_release_driver(). > > > > > > I think the current code is better than any of the alternatives considered > > > > so far. > > > > > > Then you think Guennadi should leave his patch as it is, including the > > > "reversed" put/get? > > > > This, or we need to remove the runtime PM calls from __device_release_driver(). > > Let's go back to first principles. The underlying problem we want to > solve is that runtime PM callbacks race with driver unbinding. In a > worst-case scenario, a driver module might be unbound and unloaded from > memory and then a runtime PM callback could occur, causing an invalid > memory access. > > Related to this is the fact that some drivers want to use runtime PM > from within their remove routines. This implies that the PM core > shouldn't simply disallow all runtime PM callbacks during unbinding. > > As it happens, the PM core doesn't call drivers' runtime PM routines > directly. Instead it calls bus, type, class, and power-domain > routines -- which may in turn invoke the driver routines. > > Put together, this all suggests that the PM core can't solve the > underlying problem and shouldn't try. Instead, it should be up to the > subsystems to insure they don't make invalid callbacks. For example, > the USB subsystem does this by explicitly doing pm_runtime_get_sync() > before unbinding a driver. Other subsystems would want to use a > different approach. > > If we add this requirement then yes, it would make sense to remove the > get_noresume and put_sync calls from __device_release_driver(). We > probably want to keep the barrier, though. > > > I'm a bit worried about the driver_sysfs_remove() and the bus notifier that > > in theory may affect the runtime PM callbacks potentially executed before > > ->remove() is called. > > The driver_sysfs_remove() call merely gets rid of a couple of symlinks > in sysfs. I don't think that will impact runtime PM. > > The bus notifier might, however. Not only it might, but it actually does. There are platforms currently in the ARM tree where the runtime PM hadling of devices is set up and cleaned up by the bus notifier, so after the notifier has run the device will be handled That should eliminate the race between the notifier and runtime PM and still allow the bus/driver to use runtime PM in the ->remove() callbacks. Thanks, Rafael --- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html differently. > Perhaps the barrier should be moved down, after the notifier call. > How does this patch look? > > drivers/base/dd.c | 6 +----- > 1 file changed, 1 insertion(+), 5 deletions(-) > > Index: usb-2.6/drivers/base/dd.c > =================================================================== > --- usb-2.6.orig/drivers/base/dd.c > +++ usb-2.6/drivers/base/dd.c > @@ -316,15 +316,13 @@ static void __device_release_driver(stru > > drv = dev->driver; > if (drv) { > - pm_runtime_get_noresume(dev); > - pm_runtime_barrier(dev); > - > driver_sysfs_remove(dev); > > if (dev->bus) > blocking_notifier_call_chain(&dev->bus->p->bus_notifier, > BUS_NOTIFY_UNBIND_DRIVER, > dev); > + pm_runtime_barrier(dev); The barrier would not prevent the race between the notifier and runtie PM from taking place. Why don't we do something like this instead: --- drivers/base/dd.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) Index: linux-2.6/drivers/base/dd.c =================================================================== --- linux-2.6.orig/drivers/base/dd.c +++ linux-2.6/drivers/base/dd.c @@ -326,6 +326,8 @@ static void __device_release_driver(stru BUS_NOTIFY_UNBIND_DRIVER, dev); + pm_runtime_put_sync(dev); + if (dev->bus && dev->bus->remove) dev->bus->remove(dev); else if (drv->remove) @@ -338,7 +340,6 @@ static void __device_release_driver(stru BUS_NOTIFY_UNBOUND_DRIVER, dev); - pm_runtime_put_sync(dev); } }