public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Maxim <maximlevitsky@gmail.com>
To: Pete Zaitcev <zaitcev@redhat.com>
Cc: Alan Stern <stern@rowland.harvard.edu>,
	gregkh@suse.de,
	Kernel development list <linux-kernel@vger.kernel.org>,
	USB development list <linux-usb-devel@lists.sourceforge.net>,
	davidz@redhat.com
Subject: Re: USB: on suspend to ram/disk all usb devices are replugged
Date: Wed, 28 Mar 2007 01:29:10 +0200	[thread overview]
Message-ID: <200703280129.10197.maximlevitsky@gmail.com> (raw)
In-Reply-To: <20070327110524.975e7113.zaitcev@redhat.com>

On Tuesday 27 March 2007 20:05:24 Pete Zaitcev wrote:
> On Tue, 27 Mar 2007 13:15:14 -0400 (EDT), Alan Stern <stern@rowland.harvard.edu> wrote:
> 
> > > Suspend to disk still causes "virtual replugging"  and I think that controller is reset and will unplug/replug devices anyway
> > > Resolving this problem is very difficult. Maybe it possible to check on unplugging event that this caused by suspend  if the same device is
> > > replugged then don't remove/reinstall driver, but this is very difficult to implement properly,
> > > Maybe just refuse to suspend if some valuable device is connected (sorry if it is done this way already)
> > 
> > Long ago I posted a patch that would take care of all this.  Not just for
> > UHCI, but for any USB controller.  Maybe I should dig it out, update it,
> > and submit it.
> 
> Alan, BTW, look at this please:
> 
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=233697
> 
> > From David Zeuthen
> 
> > If I suspend my box, then on the resume path I see all my USB devices being
> > removed and then added back. This is a problem with storage devices connected
> > via USB.
> .....
> > The kernel not send an "remove" event if it's going to send an "add" right
> > after. Instead it should enumerate the bus on resume and only send the events
> > that represents how to get from the previous device tree to the current one.
> 
> > From Pete Zaitcev
> 
> > What does happen if a user suspends, unplugs a USB key, modifies its contents,
> > plugs it back, and resumes? In such a case, there would be no change between
> > the state of USB bus between the before-suspend state and after-resume state.
> 
> > From David Zeuthen
> 
> > In that case the user would see data corruption - just as if he mounts a piece
> > of removable media in a USB card reader; yanks out the card and modifies it
> > elsewhere, and then puts it back in.
> 
> > I my opinion we can't really defend ourselves against such users... We can of
> > course add checks in the file system drivers in the resume hooks to validate the
> > super block and mount read-only if something change. 
> 
> The GNOME hath spoken?
> 
> -- Pete
> 

Hi, 
	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 ?

	Regards,
		Maxim Levitsky

  reply	other threads:[~2007-03-27 23:29 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-27 16:24 USB: on suspend to ram/disk all usb devices are replugged Maxim Levitsky
2007-03-27 17:15 ` Alan Stern
2007-03-27 17:54   ` Maxim
2007-03-27 18:05   ` Pete Zaitcev
2007-03-27 23:29     ` Maxim [this message]
2007-04-01 15:29       ` Pavel Machek
2007-04-01 17:42         ` David Zeuthen
2007-04-01 17:50           ` Pavel Machek
2007-04-01 18:01             ` David Zeuthen
2007-04-01 18:29               ` Pavel Machek
2007-04-01 18:26             ` Alan Stern
2007-04-01 18:34               ` Pavel Machek
2007-04-01 20:53                 ` Rafael J. Wysocki
2007-04-02  2:54                   ` Alan Stern
2007-04-02 20:37                     ` Rafael J. Wysocki
2007-04-02 18:38               ` Chuck Ebbert
2007-04-02 19:36                 ` Pavel Machek
2007-04-06 22:23                   ` Nigel Cunningham
2007-04-02 14:49             ` Mark Lord
2007-04-02 18:28               ` Pavel Machek
2007-03-29 13:19 ` Mark Lord
2007-03-29 15:56   ` Alan Stern
2007-03-29 16:03     ` Mark Lord

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200703280129.10197.maximlevitsky@gmail.com \
    --to=maximlevitsky@gmail.com \
    --cc=davidz@redhat.com \
    --cc=gregkh@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb-devel@lists.sourceforge.net \
    --cc=stern@rowland.harvard.edu \
    --cc=zaitcev@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox