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. Regards, Nigel - 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
