On Wednesday, 2 of January 2008, Nigel Cunningham wrote: > Hi. > > Rafael J. Wysocki wrote: > > On Wednesday, 2 of January 2008, Erik Andrén wrote: > >> Hi, > >> > >> 2008/1/2, Shaohua Li <shaohua.li@xxxxxxxxx>: > >>> ACPI defines a hardware signature. BIOS calculates the signature > >>> according to hardware configure, if hardware changes, the signature will > >>> change, in this case, S4 resume should fail. > >>> > >>> Signed-off-by: Shaohua Li <shaohua.li@xxxxxxxxx> > >>> --- > >> > >> Would it be possible to extend this mechanism to prevent the following > >> scenario: > >> > >> 1. Linux image A is suspended to disk > >> 2. Linux image B is booted and various changes to the system are done. > >> 3. Linux image B is shut down > >> 4. Linux image A is booted, restoring the suspend to disk image. > >> 5. Chaos is ensured as the file system state is changed in regard to how > >> linux image A expects it. > >> > >> Correct behaviour would naturally be that image A detects that changes have > >> been made under its feet and proceed to perform a normal boot instead of > >> resuming the stored suspend-to-disk image. > > > > It should be possible in theory. > > > >> Is there another mechanism preventing this? > > > > Not at the kernel level, but you can prevent this from happening by running > > mkswap on all swap spaces that refuse to come up after a fresh boot. > > We really should do something about this. It should be possible to > handle this properly if something along the following lines was implemented: > > 1) Each filesystem implements a function taking a pointer to a struct > block_device and returns a mount count for that filesystem without > making any modifications to the filesystem. > 2) Hibernation implementations store the major & minor numbers and mount > counts for each mounted filesystem in the image header when hibernating, > and recheck those values at resume time. If the mount count on any > filesystem has changes, we warn the user, invalidate the image and boot > normally. That may quickly become complicated. For example, boot kernel need not contain all drivers used by the hibernated ones, so some filesystems may be physically inaccessible to them. Greetings, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
