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. Alan Stern
