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 for Android: free password hash cracker in your pocket

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

Date:	Fri, 3 Aug 2007 10:41:13 -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:

> Windows will autosuspend hubs, bluetooth devices, HID devices and CDC 
> devices, so I think we're safe suspending those by default.

And we know that we're not safe suspending scanners and many printers 
by default.  But that leaves plenty of other device classes unaccounted 
for.

> I'm not so 
> enthusiastic about the "Increase the timeout case" - it doesn't avoid 
> any races, just makes them less likely. USB is likely to get loaded in 
> the initramfs, but we may not have a full set of udev rules until the 
> root fs is up and that can take an effectively arbitrarily large amount 
> of time.

If it takes longer than 15 minutes, something is wrong.  At that point 
the user will have worse things to worry about than whether some USB 
devices got suspended.

And 15 minutes is a perfectly reasonable autosuspend timeout for 
devices that might be plugged in all day long.

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/