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]
Message-ID: <3703451.5FViJ58GpZ@linux-5eaq.site>
Date:	Tue, 05 Mar 2013 13:50:35 +0100
From:	Oliver Neukum <oneukum@...e.de>
To:	Ming Lei <ming.lei@...onical.com>
Cc:	Bjørn Mork <bjorn@...k.no>,
	"David S. Miller" <davem@...emloft.net>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Jiri Kosina <jkosina@...e.cz>,
	Alan Stern <stern@...land.harvard.edu>, netdev@...r.kernel.org,
	linux-usb@...r.kernel.org, linux-input@...r.kernel.org
Subject: Re: [PATCH 0/7] USB: don't recover device if suspend fails in system sleep

On Tuesday 05 March 2013 18:55:42 Ming Lei wrote:
> > All these drivers suspend in multiple steps, where each step can
> > fail. If a later step fails then they revert any previously successful
> > step before returning the failure, thereby ensuring that the
> > device/driver state when suspend returns is consistently either
> > suspended or resumed.
> 
> IMO, for autosuspend, that is right, but it is not for system suspend,
> and the driver's suspend callback can't return in resumed state
> because the USB core will ignore the failure return value and force
> to suspend the device.

It seems to me that in this case you just need to make sure that
suspend() not fail for system suspend. Or revisit the decision to
ignore failures.
In other words, if we don't handle errors, there must be no errors,
otherwise it doesn't matter what we do in the error case. We'd leave
the problem to generic layers.

Furthermore there is a small chance that although the device tree
is walked, teh system suspend fails for another later reason that
is not ignored. In that case the drivers need to do error recovery,
albeit in resume().

	Regards
		Oliver

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ