linux-kernel - Re: [PATCH] usb: Make USB persist default configurable

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: <Pine.LNX.4.44L0.1303191139080.15684-100000@netrider.rowland.org>
Date:	Tue, 19 Mar 2013 11:42:25 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Vincent Palatin <vpalatin@...omium.org>
cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Julius Werner <jwerner@...omium.org>,
	LKML <linux-kernel@...r.kernel.org>, <linux-usb@...r.kernel.org>,
	Lan Tianyu <tianyu.lan@...el.com>,
	Sameer Nanda <snanda@...omium.org>,
	Luigi Semenzato <semenzato@...omium.org>
Subject: Re: [PATCH] usb: Make USB persist default configurable

On Tue, 19 Mar 2013, Vincent Palatin wrote:

> > The races mentioned above don't seem to be very dangerous.  How likely
> > is it that the system will be suspended within a few milliseconds of
> > probing a new USB device?
> 
> For laptops, if the suspend/resume is triggered by the lid open/close
> detection, this is somewhat likely and bit us in the past :
>  the classical use case I have encountered is a back-to-back suspend
> triggered by the user opening the lid then closing it again in the
> next 2 or 3 seconds because he has changed is mind (damn user...),
> might be also triggered by lid hall sensor missing proper debouncing
> (but in that case, the mechanical time constant is often shorter than
> the latency of resuming USB devices).

Yes, okay, that's true.  If a new USB device is plugged in while the 
lid is shut, and then the lid is opened very briefly, it's possible 
that the system could suspend again before the new device's "persist" 
attribute is updated.  Does that case really matter?  The device isn't 
likely to be in use at that point.

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/