Re: [linux-pm] Re: [patch] hibernation: utilize ACPI hardware signature
Hi. Rafael J. Wysocki wrote: > On Wednesday, 2 of January 2008, Erik Andrén wrote: >> Hi, >> >> 2008/1/2, Shaohua Li <[EMAIL PROTECTED]>: >>> 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 <[EMAIL PROTECTED]> >>> --- >> >> 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] Re: [patch] hibernation: utilize ACPI hardware signature
Hi. Rafael J. Wysocki wrote: > On Wednesday, 2 of January 2008, Shaohua Li wrote: >> 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. > > The idea is fine, but I'd prefer to do that in a more straightforward way. > Namely, we can just: > * write the signature into a variable in, for example, > acpi_hibernation_prepare() (then, the "old" signature value will be > automatically saved in the image) > * compare it with a the "new" value read from the BIOS in > acpi_hibernation_leave() and panic if there's a mismatch > * add a configuration option to disable this behavior (just in case) > This way we can avoid modifying the entire generic interface to add the > feature > specific to ACPI. > > Still, if you want the boot kernel to check the signature, which will be more > elegant (but please note that on x86-64 the boot kernel need not support ACPI > at all), you can use the (recently introduced) architecture part of the image > header for this purpose, without modifying the generic interface. I suppose we can always disable this when we start to support hardware changing over hibernate (I have ideas in this direction - memory cold plugging, for a start). Regards, Nigel - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] Re: [patch] hibernation: utilize ACPI hardware signature
On Wednesday, 2 of January 2008, Nigel Cunningham wrote: > Hi. > > Rafael J. Wysocki wrote: > > On Wednesday, 2 of January 2008, Shaohua Li wrote: > >> 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. > > > > The idea is fine, but I'd prefer to do that in a more straightforward way. > > Namely, we can just: > > * write the signature into a variable in, for example, > > acpi_hibernation_prepare() (then, the "old" signature value will be > > automatically saved in the image) > > * compare it with a the "new" value read from the BIOS in > > acpi_hibernation_leave() and panic if there's a mismatch > > * add a configuration option to disable this behavior (just in case) > > This way we can avoid modifying the entire generic interface to add the > > feature > > specific to ACPI. > > > > Still, if you want the boot kernel to check the signature, which will be > > more > > elegant (but please note that on x86-64 the boot kernel need not support > > ACPI > > at all), you can use the (recently introduced) architecture part of the > > image > > header for this purpose, without modifying the generic interface. > > I suppose we can always disable this when we start to support hardware > changing over hibernate (I have ideas in this direction - memory cold > plugging, for a start). Well, if we support such features, we won't be following ACPI any more. Greetings, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] Re: [patch] hibernation: utilize ACPI hardware signature
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 <[EMAIL PROTECTED]>: > >>> 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 <[EMAIL PROTECTED]> > >>> --- > >> > >> 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] Re: [patch] hibernation: utilize ACPI hardware signature
Hi. Rafael J. Wysocki wrote: 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. Mmmm. That's true, and I'd never heard that point raised before or thought of it myself. Thanks! Nigel - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] Re: [patch] hibernation: utilize ACPI hardware signature
Hi. Rafael J. Wysocki wrote: >> I suppose we can always disable this when we start to support hardware >> changing over hibernate (I have ideas in this direction - memory cold >> plugging, for a start). > > Well, if we support such features, we won't be following ACPI any more. Mmm. Apparently I'm not as focused on specs as you :). I was starting to think through whether it could make for a new and much faster was to boot live cds - something along the lines of complete redetection of hardware and memory cold plugging. Of course it's only in the 'I wonder if this would be possible' stage at the mo, but seemed at least feasible - keep the e820 tables from boot, make _init routines not get thrown away and do something like the kexec device shutdown etc around an atomic restore. I know there'd be limitations, but perhaps worth thinking about... Nigel - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] Re: [patch] hibernation: utilize ACPI hardware signature
On Thursday, 3 of January 2008, Nigel Cunningham wrote: > Hi. > > Rafael J. Wysocki wrote: > >> I suppose we can always disable this when we start to support hardware > >> changing over hibernate (I have ideas in this direction - memory cold > >> plugging, for a start). > > > > Well, if we support such features, we won't be following ACPI any more. > > Mmm. Apparently I'm not as focused on specs as you :). > > I was starting to think through whether it could make for a new and much > faster was to boot live cds - something along the lines of complete > redetection of hardware and memory cold plugging. Of course it's only in > the 'I wonder if this would be possible' stage at the mo, but seemed at > least feasible - keep the e820 tables from boot, make _init routines not > get thrown away and do something like the kexec device shutdown etc > around an atomic restore. > > I know there'd be limitations, but perhaps worth thinking about... Well, what if the new e820 map is incompatible with the old one? Rafael - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] Re: [patch] hibernation: utilize ACPI hardware signature
Hi. Rafael J. Wysocki wrote: > On Thursday, 3 of January 2008, Nigel Cunningham wrote: >> Hi. >> >> Rafael J. Wysocki wrote: I suppose we can always disable this when we start to support hardware changing over hibernate (I have ideas in this direction - memory cold plugging, for a start). >>> Well, if we support such features, we won't be following ACPI any more. >> Mmm. Apparently I'm not as focused on specs as you :). >> >> I was starting to think through whether it could make for a new and much >> faster was to boot live cds - something along the lines of complete >> redetection of hardware and memory cold plugging. Of course it's only in >> the 'I wonder if this would be possible' stage at the mo, but seemed at >> least feasible - keep the e820 tables from boot, make _init routines not >> get thrown away and do something like the kexec device shutdown etc >> around an atomic restore. >> >> I know there'd be limitations, but perhaps worth thinking about... > > Well, what if the new e820 map is incompatible with the old one? In the worst case, you tell the user about it and carry on with the old one. Perhaps this would be the killer for the live cd idea - perhaps e820 maps vary too much, there'd be no possible workaround and this would never be practical. It's worth at least thinking about, though, isn't it? Nigel - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
