Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933207Ab0FBWO0 (ORCPT ); Wed, 2 Jun 2010 18:14:26 -0400 Received: from ogre.sisk.pl ([217.79.144.158]:43930 "EHLO ogre.sisk.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932937Ab0FBWOY (ORCPT ); Wed, 2 Jun 2010 18:14:24 -0400 From: "Rafael J. Wysocki" To: Neil Brown Subject: Re: [PATCH] - race-free suspend. Was: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8) Date: Thu, 3 Jun 2010 00:15:32 +0200 User-Agent: KMail/1.12.4 (Linux/2.6.35-rc1-rjw; KDE/4.3.5; x86_64; ; ) Cc: Thomas Gleixner , Alan Stern , Felipe Balbi , Arve =?iso-8859-1?q?Hj=F8nnev=E5g?= , Peter Zijlstra , "Paul@smtp1.linux-foundation.org" , LKML , Florian Mickler , Linux OMAP Mailing List , Linux PM , Alan Cox , James Bottomley References: <201006022241.14152.rjw@sisk.pl> <20100603080556.46d2d671@notabene.brown> In-Reply-To: <20100603080556.46d2d671@notabene.brown> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201006030015.32313.rjw@sisk.pl> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1655 Lines: 39 On Thursday 03 June 2010, Neil Brown wrote: > On Wed, 2 Jun 2010 22:41:14 +0200 > "Rafael J. Wysocki" wrote: > > > On Wednesday 02 June 2010, Neil Brown wrote: > > > - Would this fix the "bug"?? > > > - and address the issues that suspend-blockers was created to address? > > > - or are the requirements on user-space too onerous? > > > > In theory wakeup events can also happen after wait_for_blockers() has returned > > 0 and I guess we should rollback the suspend in such cases. > > > > I naively assumed this was already the case, but on a slightly closer look at > the code it seems not. > > Presumably there is some point deep in the suspend code, probably after the > call to sysdev_suspend, where interrupts are disabled and we are about to > actually suspend. At that point a simple "is a roll-back required" test > could abort the suspend. Yes. > Then any driver that handles wake-up events, if it gets and event that (would > normally cause a wakeup) PM_SUSPEND_PREPARE and PM_POST_SUSPEND, could set > the "roll-back is required" flag. That's my idea, but instead of setting a flag, I'd use a counter increased every time there is a wakeup event. Then, the core suspend core code would store a pre-suspend value of the counter and compare it with the current value after all wakeup event sources had been set. If they were different, the suspend would be aborted. Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/