linux-kernel - Re: [PATCH] USB: Only enable autosuspend by default on certain device classes

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:	Fri, 3 Aug 2007 10:28:19 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Matthew Garrett <mjg59@...f.ucam.org>
cc:	David Brownell <david-b@...bell.net>,
	Rogan Dawes <lists@...es.za.net>,
	Oliver Neukum <oliver@...kum.org>, Greg KH <gregkh@...e.de>,
	<linux-usb-devel@...ts.sourceforge.net>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] USB: Only enable autosuspend by   default on certain
 device classes

On Fri, 3 Aug 2007, Matthew Garrett wrote:

> This patch is exactly that - a way of getting most of the benefits of 
> autosuspend without any real probability of breaking hardware. If you 
> mean "Are the distributions willing to pop up dialogs asking users to 
> start caring about obscure aspects of the USB spec", then I don't think 
> that's actually making things better.

Quite aside from issues involving desktop ease-of-use and distribution 
intentions, there is a technical matter to consider.  With the default 
autosuspend timeout set to 2 seconds, as it is now, it can often happen 
that userspace isn't able to respond in time to prevent a device from 
being suspended.  At bootup especially, the system is so busy running 
lots of tasks that response to a newly-detected device can be delayed 
for tens of seconds.  Even loading the device driver's module can take 
so long that the device gets autosuspended first.

There are two possible solutions, both involving the kernel (since
userspace can't respond in time).  One is to change the default timeout
to something larger, or even disable it completely.  Then people would
need to rely on userspace tools to enable autosuspend on known-good
devices.  The other possibility is to have a fairly reliable blacklist
or whitelist and again rely on userspace to manage edge cases.  This is 
of course more flexible than a blanket default setting, but it's still 
pretty rigid.  On the other hand, a blacklist can't be changed without 
rebuilding the kernel whereas the default timeout can be adjusted on 
the boot command line.

I don't know what the "best" approach is, but I can't see any
alternative to these two.  Furthermore, whatever approach we settle on
_has_ to be able to handle devices which simply die upon being 
suspended.

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/