linux-kernel - Re: [RFC][PATCH] PM: Introduce new top level suspend and hibernation callbacks (rev. 2)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 22 Mar 2008 19:28:02 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
cc:	pm list <linux-pm@...ts.linux-foundation.org>,
	ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
	Greg KH <greg@...ah.com>, Len Brown <lenb@...nel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Alexey Starikovskiy <astarikovskiy@...e.de>,
	David Brownell <david-b@...bell.net>,
	Pavel Machek <pavel@....cz>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>
Subject: Re: [RFC][PATCH] PM: Introduce new top level suspend and hibernation
 callbacks (rev. 2)

On Sat, 22 Mar 2008, Rafael J. Wysocki wrote:

> > Yep.  The only thing to watch out for is in device_pm_remove(); it
> > would be a disaster if somehow a device was removed while it was being
> > prepared/suspended/resumed/completed/whatever.  I know that's not
> > supposed to happen but there's nothing to prevent it, especially if
> > the device in question doesn't have a driver.  No doubt you can invent
> > a way to allow this to happen safely.
> 
> Well, that's a separate issue that IMO should be addressed in a separate patch.
> Something like the one below comes to mind.
> 
> The comment removed by the patch is wrong IMO, because it implies that
> device_add() may be called with the device semaphore held and that might
> deadlock in bus_attach_device().

Are you talking about this comment?

> - * Since device_pm_add() may be called with a device semaphore held,
> - * we must never try to acquire a device semaphore while holding
> - * dpm_list_mutex.

It isn't wrong.  device_add() may indeed be called with a device 
semaphore held -- just not the semaphore for the device being added.  
Quite often it is called with device's parent's semaphore held.  The 
implication is not that we may deadlock in bus_attach_device(); rather 
it is that the order of acquisition must always be device semaphore 
first, dev_list_mutex second.

>  Thus, I think we can acquire dev->sem
> in device_pm_add() and in device_pm_remove().

No, you have missed the entire point.  The problem doesn't exist in the
current code; it exists only if we switch over to using a single list.  
Routines like dpm_suspend() won't be able to use list_for_each_entry()
to traverse the list because entries may be removed by other threads
during the traversal.  Even list_for_each_entry_safe() won't work
correctly without careful attention to details.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/