All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Nigel Cunningham <nigel@suspend2.net>,
	Linux-pm mailing list <linux-pm@lists.osdl.org>, "Victor Porton, ,
	, " <porton@ex-code.com>
Subject: Re: Re: standby to disk transition
Date: Tue, 14 Mar 2006 23:07:21 +0100	[thread overview]
Message-ID: <200603142307.22355.rjw@sisk.pl> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0603141636060.1003-100000@iolanthe.rowland.org>

On Tuesday 14 March 2006 22:42, Alan Stern wrote:
> On Tue, 14 Mar 2006, Pavel Machek wrote:
> 
> > > > Even if you make sure *kernel* is consistent with changed filesystem,
> > > > userland is going to be badly confused. Imagine what will happen with
> > > > memory mapped files, for example. 
> > > 
> > > Something like what happens when you suspend with a mounted CD
> > > and mmapped files from there, then you replace the CD while suspended
> > > and resume.  Not a wise thing to do, but I think people will do such things
> > > from time to time and we'd better be prepared to handle them nicely.
> > 
> > But... we can't prevent userspace from segfaulting in such case... can
> > we?
> > 
> > > > I'm not sure how it could work...
> > > 
> > > IMO memory mapped files are the most difficult problem here,
> > > but the rest seems to be doable in general.
> > 
> > It seems to be the same problem with removable media... You could
> > replace mounted CDrom while running. (Not all CDroms support door
> > lock.)
> 
> In theory, any SCSI device is supposed to realize when the medium has been 
> changed and notify the host by responding to the next command with a Unit 
> Attention sense key.  That's how medium changes while the system _isn't_ 
> suspended get detected.
> 
> The situation becomes much more problematic when the SCSI device itself is
> powered off.  In that case (which includes the "hardware doesn't support
> USB power during suspend" problem discussed at great length earlier), the
> kernel has only two choices.  Either assume that the medium _has_ been
> changed -- or more generally, that a new device is present -- or else try
> to verify somehow that the current medium is the same as the old medium.
> 
> This verification can't be certain, so there would always be a chance for 
> error.  Besides, right now the kernel contains no code for making such 
> verifications.

The question here, as far as I understand it, is whether we can write such a
code and, if so, whether it's worth doing.  I'm not sure of any of these now,
but the problem is interesting. :-)

Greetings,
Rafael

  reply	other threads:[~2006-03-14 22:07 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-13  2:34 standby to disk transition Victor Porton,,,
2006-03-13  8:30 ` Pavel Machek
2006-03-13  8:48   ` Adam Belay
2006-03-13  8:50     ` Pavel Machek
2006-03-13  9:07       ` Adam Belay
2006-03-13  9:13         ` Pavel Machek
2006-03-13 18:33           ` Dave Jones
2006-03-13 21:24             ` Pavel Machek
2006-03-13 21:28               ` Dave Jones
2006-03-13 21:46                 ` Pavel Machek
2006-03-13 22:06                   ` Rafael J. Wysocki
2006-03-13 21:59                 ` Nigel Cunningham
2006-03-13 22:08                   ` Pavel Machek
2006-03-13 22:42                     ` Rafael J. Wysocki
2006-03-13 23:11                       ` Nigel Cunningham
2006-03-13 23:36                         ` Rafael J. Wysocki
2006-03-14  0:18                           ` Nigel Cunningham
2006-03-14 18:12                             ` Rafael J. Wysocki
2006-03-14 20:33                           ` Pavel Machek
2006-03-14 21:13                             ` Rafael J. Wysocki
2006-03-14 21:22                               ` Pavel Machek
2006-03-14 21:42                                 ` Alan Stern
2006-03-14 22:07                                   ` Rafael J. Wysocki [this message]
2006-03-15 15:14                                     ` Alan Stern
2006-03-14 21:57                                 ` Rafael J. Wysocki
2006-03-14 21:59                               ` Pavel Machek
2006-03-15  0:22                                 ` suspend-to-both [was Re: Re: standby to disk transition] Pavel Machek
2006-03-14 20:29                         ` Re: standby to disk transition Pavel Machek
2006-03-14  0:21               ` Nigel Cunningham
2006-03-14  9:50                 ` Pavel Machek
2006-03-13 13:55     ` Nigel Cunningham

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=200603142307.22355.rjw@sisk.pl \
    --to=rjw@sisk.pl \
    --cc=linux-pm@lists.osdl.org \
    --cc=nigel@suspend2.net \
    --cc=porton@ex-code.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.