[Pm-utils] [patch] disable suspend when kernel image changed

[Dan Nicholson]

On Fri, Apr 9, 2010 at 3:15 AM, Richard Zidlicky <rz at linux-m68k.org> wrote:
> On Thu, Apr 08, 2010 at 09:31:47PM +0200, Rafael J. Wysocki wrote:
>> On Thursday 08 April 2010, Nigel Cunningham wrote:
>> > Hi.
>> >
>> > On 08/04/10 20:25, Richard Zidlicky wrote:
>> > > On Thu, Apr 08, 2010 at 07:06:31PM +1000, Nigel Cunningham wrote:
>> > >> On 08/04/10 05:52, Richard Zidlicky wrote:
>> > >>> Hi,
>> > >>>
>> > >>> trying to fix this crash situation: /boot/vmlinuz-XXX exists and is the currently
>> > >>> running kernel, I decide to reconfigure and recompile it, overwrite /boot/vmlinuz-XXX
>> > >>> and hit pm-hibernate.
>> > >>>
>> > > ...
>> > > ...
>> > >>>
>> > >>> --- 01grub.rz   2010-04-07 19:52:02.000000000 +0200
>> > >>> +++ 01grub      2010-04-07 21:22:30.000000000 +0200
>> > >>> @@ -15,6 +15,7 @@
>> > >>>
>> > >>>           [ -x /sbin/grubby -a -x /sbin/grub ] || return $NA
>> > >>>           [ -e "/boot/vmlinuz-$(uname -r)" ] || return 1
>> > >>> +       [ /var/log/boot.log -ot "/boot/vmlinuz-$(uname -r)" ]&&   return $NA
>> > >>>           out=$(/sbin/grubby --info /boot/vmlinuz-$(uname -r) |grep index)
>> > >>>           [ -n "${out}" ] || return 1
>> > >>>           current=${out#index=}
>> > >>
>> > >> With anything relatively recent (post about 2.6.27 IIRC), this should be
>> > >> unnecessary. Code has been added so that you can hibernate with one
>> > >> kernel and resume with another.
>> > >
>> > > definitely not the case - just triggered it with 2.6.33.2 yesterday:
>> > >
>> > > Apr  7 16:23:45 localhost kernel: [   23.188781] Freezing user space processes ... (elapsed 0.01 seconds) done.
>> > > Apr  7 16:23:45 localhost kernel: [   23.199054] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
>> > > Apr  7 16:23:45 localhost kernel: [   23.222282] PM: Loading image data pages (182231 pages) ...
>> > > Apr  7 16:23:45 localhost kernel: [   23.222310] PM: Image mismatch: version
>> > > Apr  7 16:23:45 localhost kernel: [   23.222355]
>> > > Apr  7 16:23:45 localhost kernel: [   23.222378] PM: Read 728924 kbytes in 0.01 seconds (72892.40 MB/s)
>> > > Apr  7 16:23:45 localhost kernel: [   23.222433] PM: Restore failed, recovering.
>> > > Apr  7 16:23:45 localhost kernel: [   23.230013] Restarting tasks ... done.
>> > > Apr  7 16:23:45 localhost kernel: [   24.047245] EXT3-fs (dm-6): recovery required on readonly filesystem
>> > >
>> > > it was exactly the same kernel release - only slightly reconfigured&  recompiled.
>> >
>> > Hmm. My apologies; you're absolutely right.
>> >
>> > I'll have to email Rafael (cc'd) - I'm not sure why that check is still
>> > there. I know it is possible for you to hibernate one kernel and resume
>> > from another - I've done it with TuxOnIce using the low-level code
>> > Rafael put in. Perhaps he's discovered something that makes it
>> > unreliable or such like.
>>
>> That still should work, although only on x86-64, because I've never had the
>> time to implement it on x86-32.
>>
>> That said, I haven't tried it myself recently and the feature might regress due
>> to the general x86 change flow.
>
> so it is something that does not work at the moment but might get implemented.
> If so, is there any possibility to test at runtime whether it will work with
> a particular combination of kernel images?
>
> Somehow pm-utils needs to safeguard against current situation where a resume can
> fail with data loss so if the feature can not be reliably detected I would still
> advocate to disable it in circumstances where it can not be guaranteed to work.

I'm not sure I think this is really a big issue for pm-utils. 99% of
people will be using their distro's kernel that has the full version
in the filename, so they'll never have their current kernel image
overwritten. Overwriting the image of your currently running kernel
and then intentionally hibernating seems to be a pretty risky
maneuver, and I don't think pm-utils should be trying to safeguard the
very few people who try to do it. There's a simpler solution to this
problem: don't do it.

--
Dan