Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759923AbYBXTDZ (ORCPT ); Sun, 24 Feb 2008 14:03:25 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753597AbYBXTDH (ORCPT ); Sun, 24 Feb 2008 14:03:07 -0500 Received: from netrider.rowland.org ([192.131.102.5]:2565 "HELO netrider.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1753139AbYBXTDG (ORCPT ); Sun, 24 Feb 2008 14:03:06 -0500 Date: Sun, 24 Feb 2008 14:03:02 -0500 (EST) From: Alan Stern X-X-Sender: stern@netrider.rowland.org To: Pavel Machek cc: "Rafael J. Wysocki" , Pierre Ossman , Zdenek Kabelac , Kernel development list , pm list Subject: Re: [Bug 10030] Suspend doesn't work when SD card is inserted In-Reply-To: <20080224182120.GB3886@ucw.cz> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1689 Lines: 52 On Sun, 24 Feb 2008, Pavel Machek wrote: > Hi! > > > Index: usb-2.6/drivers/base/power/main.c > > =================================================================== > > --- usb-2.6.orig/drivers/base/power/main.c > > +++ usb-2.6/drivers/base/power/main.c > > @@ -25,6 +25,7 @@ > > #include > > #include > > #include > > +#include > > > > #include "../base.h" > > #include "power.h" > > @@ -59,6 +60,13 @@ static DECLARE_RWSEM(pm_sleep_rwsem); > > > > int (*platform_enable_wakeup)(struct device *dev, int is_on); > > > > +static struct task_struct *suspending_task; > > What locking protects this variable? What happens when suspending_task > exits? (Hmm, that would probably be bug, anyway?) It's protected by whatever existing locking scheme allows only one task to start a system sleep at a time. For example, the suspending task has to get a write lock on pm_sleep_rwsem. Yes, if the suspending task exits before the system has woken up, you're in trouble regardless. > Or are we running UP when this is accessed? This at least needs a big > fat comment. > > > +bool in_suspend_context(void) > > +{ > > + return (suspending_task == current); > > +} We aren't necessarily UP. But since all that matters is whether or not suspend_task is equal to the current task, no extra locking is needed. I'll add a comment explaining all this. Alan Stern -- 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/