All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alan Stern <stern@rowland.harvard.edu>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Linux PM mailing list <linux-pm@lists.linux-foundation.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Jesse Barnes <jbarnes@virtuousgeek.org>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>
Subject: Re: [PATCH] PCI / PM: Block races between runtime PM and system sleep
Date: Mon, 20 Jun 2011 10:46:13 -0400 (EDT)	[thread overview]
Message-ID: <Pine.LNX.4.44L0.1106201039580.2113-100000@iolanthe.rowland.org> (raw)
In-Reply-To: <201106192149.19401.rjw@sisk.pl>

On Sun, 19 Jun 2011, Rafael J. Wysocki wrote:

> From: Rafael J. Wysocki <rjw@sisk.pl>
> 
> After commit e8665002477f0278f84f898145b1f141ba26ee26
> (PM: Allow pm_runtime_suspend() to succeed during system suspend) it
> is possible that a device resumed by the pm_runtime_resume(dev) in
> pci_pm_prepare() will be suspended immediately from a work item,
> timer function or otherwise, defeating the very purpose of calling
> pm_runtime_resume(dev) from there.  To prevent that from happening
> it is necessary to increment the runtime PM usage counter of the
> device by replacing pm_runtime_resume() with pm_runtime_get_sync().
> Moreover, the incremented runtime PM usage counter has to be
> decremented by the corresponding pci_pm_complete(), via
> pm_runtime_put_noidle().

In both this and the previous patch, the final decrement should be done 
by pm_runtime_put_sync() instead of pm_runtime_put_idle().  Otherwise 
you face the possibility that the usage_count may go to 0 but the 
device will be left active.

Furthermore, since we're going to disable runtime PM as soon as the
suspend callback returns anyway, why not increment usage_count before
invoking the callback?  This will prevent runtime suspends from 
occurring while the callback runs, so no changes will be needed in the 
PCI or USB subsystems.

It also will prevent Kevin from calling pm_runtime_suspend from within
his suspend callbacks, but you have already determined that subsystems
and drivers should never do that in any case.

Alan Stern


  parent reply	other threads:[~2011-06-20 14:46 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-19 19:49 [PATCH] PCI / PM: Block races between runtime PM and system sleep Rafael J. Wysocki
2011-06-20 14:46 ` Alan Stern
2011-06-20 14:46 ` Alan Stern [this message]
2011-06-20 19:42   ` Rafael J. Wysocki
2011-06-20 19:42   ` Rafael J. Wysocki
2011-06-20 21:00     ` Alan Stern
2011-06-20 21:28       ` Rafael J. Wysocki
2011-06-20 21:28       ` Rafael J. Wysocki
2011-06-21 14:52         ` Alan Stern
2011-06-21 14:52         ` Alan Stern
2011-06-21 23:49           ` Rafael J. Wysocki
2011-06-21 23:49           ` Rafael J. Wysocki
2011-06-22 14:20             ` Alan Stern
2011-06-22 14:20             ` Alan Stern
2011-06-23 17:46               ` Rafael J. Wysocki
2011-06-23 17:46               ` Rafael J. Wysocki
2011-06-23 18:35                 ` Alan Stern
2011-06-23 20:49                   ` Rafael J. Wysocki
2011-06-23 20:49                   ` Rafael J. Wysocki
2011-06-23 21:02                     ` Alan Stern
2011-06-23 21:02                     ` Alan Stern
2011-06-23 21:16                       ` Rafael J. Wysocki
2011-06-23 21:16                       ` Rafael J. Wysocki
2011-06-23 21:38                         ` Alan Stern
2011-06-23 22:35                           ` Rafael J. Wysocki
2011-06-23 22:35                           ` Rafael J. Wysocki
2011-06-23 22:59                             ` Rafael J. Wysocki
2011-06-23 22:59                             ` Rafael J. Wysocki
2011-06-26  2:39                               ` Alan Stern
2011-06-26 12:22                                 ` Rafael J. Wysocki
2011-06-26 12:22                                   ` Rafael J. Wysocki
2011-06-26  2:39                               ` Alan Stern
2011-06-23 21:38                         ` Alan Stern
2011-06-23 18:35                 ` Alan Stern
2011-06-20 21:00     ` Alan Stern
2011-06-19 19:49 Rafael J. Wysocki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.44L0.1106201039580.2113-100000@iolanthe.rowland.org \
    --to=stern@rowland.harvard.edu \
    --cc=jbarnes@virtuousgeek.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-pm@lists.linux-foundation.org \
    --cc=rjw@sisk.pl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.