public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Pete Zaitcev <zaitcev@redhat.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Maxim Levitsky <maximlevitsky@gmail.com>,
	gregkh@suse.de,
	Kernel development list <linux-kernel@vger.kernel.org>,
	USB development list <linux-usb-devel@lists.sourceforge.net>,
	zaitcev@redhat.com, davidz@redhat.com
Subject: Re: USB: on suspend to ram/disk all usb devices are replugged
Date: Tue, 27 Mar 2007 11:05:24 -0700	[thread overview]
Message-ID: <20070327110524.975e7113.zaitcev@redhat.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0703271306230.2558-100000@iolanthe.rowland.org>

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

  parent reply	other threads:[~2007-03-27 18:08 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 [this message]
2007-03-27 23:29     ` Maxim
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=20070327110524.975e7113.zaitcev@redhat.com \
    --to=zaitcev@redhat.com \
    --cc=davidz@redhat.com \
    --cc=gregkh@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb-devel@lists.sourceforge.net \
    --cc=maximlevitsky@gmail.com \
    --cc=stern@rowland.harvard.edu \
    /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