linux-kernel - Re: USB: on suspend to ram/disk all usb devices are replugged

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: <20070401175020.GE11146@elf.ucw.cz>
Date:	Sun, 1 Apr 2007 19:50:20 +0200
From:	Pavel Machek <pavel@....cz>
To:	David Zeuthen <davidz@...hat.com>
Cc:	Maxim <maximlevitsky@...il.com>, Pete Zaitcev <zaitcev@...hat.com>,
	Alan Stern <stern@...land.harvard.edu>, gregkh@...e.de,
	Kernel development list <linux-kernel@...r.kernel.org>,
	USB development list <linux-usb-devel@...ts.sourceforge.net>
Subject: Re: USB: on suspend to ram/disk all usb devices are replugged

Hi!

> > > > The GNOME hath spoken?
> > 
> > > 	I also thought about that,
> > > 	
> > > 	I think that the best solution is still to hide connect/disconnect of usb devices from userspace (now it also causes corruption)
> > > 	But to refuse suspend with any usb mass storage device connected with mounted systems (and add a module param override
> > > 	 for users who know what they are doing)
> > > 
> > > 	What do you think ?
> > 
> > Agreed... and notice how easy is to do that in userspace :-))).
> 
> The problem with refusing to suspend with usb mass storage devices
> mounted is just not going to work; the way we want desktop power

Problem is that suspending _with_ removable mass storage devices
attached just will not work. User will unplug them, then complain
about corruption. Advanced user will unplug them, work with them
somewhere else, replug them, then loose filesystem.

Feel free to send patch to teach filesystems to handle this.

> management to work is that the system automatically does s2ram or s2disk
> when
> 
>  - the system is idle
>  - the user closes the laptop lid
>    (all this is of course configurable but these are the defaults
>     in many distributions of Linux.)
> 
> and the kernel refusing to suspend in these cases may result in e.g. the
> laptop melting because the lid is closed. For example, in

Check your facts. Laptops do not melt. I know, I put them into my bed,
covered with pillow, and let them complain (evo 560c). ACPI thermals
can handle that.

> gnome-power-manager we play a loud "boohoo" sound if suspend fails when
> closing the lid. It's all we can do really, the user have closed the lid
> and if we didn't alert her _in some way_ the result would be a melted
> laptop. You have to realize that people use their system in such a
> way.

You have to realize what is possible and what is not.

> Suspending when idle is really important too, since at some point there
> will be legislation (akin to accessibility, e.g. the US's section

Yep? Create the filesystem patch, then.

> And there's this: suggesting to just provide an option for people to
> override this is not useful; any sane desktop distro will use that
> override because users _expect_ that their laptop suspends when they
> close the lid and they don't really or know care whether some drive is
> connected via USB.

If you don't care or care about your data, feel free to (patch your
kernel to) suspend with removable disks mounted.

> I hate to play this card, but you may want to look at other desktop

You are indeed should know better than speaking like this on lkml.

								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
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/