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:	Wed, 5 Mar 2008 11:03:52 -0500 (EST)
From:	Alan Stern <stern@...land.harvard.edu>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
cc:	pm list <linux-pm@...ts.linux-foundation.org>,
	Alexey Starikovskiy <astarikovskiy@...e.de>,
	Pavel Machek <pavel@....cz>,
	LKML <linux-kernel@...r.kernel.org>,
	Marcel Holtmann <marcel@...tmann.org>,
	Cornelia Huck <cornelia.huck@...ibm.com>
Subject: Re: [RFC][PATCH] PM: Make PM core handle device registrations
 concurrent with suspend/hibernation

On Tue, 4 Mar 2008, Rafael J. Wysocki wrote:

> > It's not clear that we want to have this check.  It would cause
> > problems if the device ordering got mixed up by device_move(), which is
> > pretty much the only way it could be triggered.
> 
> Well, isn't it actually dangerous to suspend parents before their children?
> What happens, for example, if putting the parent into D3 causes power to be
> cut from the children and then we attempt to suspend them?

It depends on the devices involved.  For PCI devices, obviously there 
will be problems of the sort you described.  But for other devices 
there might not be.

For example, the USB Bluetooth driver will sometimes create a new TTY
device and then move the existing Bluetooth device underneath it (this
description is oversimplified and probably wrong in some important
respects, but you get the idea).  Suspending the Bluetooth device
before suspending the TTY won't cause any power-related problems,
because a TTY is a purely logical device with no power implications at
all.

There might still be logical problems, of course...  We need to add a
mechanism for reordering the dpm_active list when device_move() is
called.  But first we need to get in touch with the people using
device_move() -- basically just Marcel and Cornelia -- and see what
sort of mechanism they will need.

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ