Re: resuming swsusp twice

[Andy Isaacson <adi@hexapodia.org>]

On Thu, Jul 14, 2005 at 04:58:12PM +0200, Stefan Seyfried wrote:
> Andy Isaacson wrote:
> > Yesterday I booted my laptop to 2.6.13-rc2-mm1, suspended to swsusp,
> > and
[snip]
> > and got a panic along the lines of "Unable to find swap space, try
>
> a panic? it should only be an error message, but the machine should
> still be alive.

Well, the console was left on the swsusp VT (guess that's not suprising)
and I was hurrying to catch the train, so I didn't investigate, I just
held down the power button for 5 seconds.

> > swapon -a".  Unfortunately I was in a hurry and didn't record the
> > error
> > messages.  I powered off, then a few minutes later powered on again.
>
> Powered off hard or "shutdown -h now"?

Hard.  It's a Thinkpad X40 with ACPI, so I hold down the power button
for a few seconds to power off.

> > At this point, it resumed *to the swsusp state from yesterday*!
[snip severe ext3 damage]
> > It's extremely unfortunate that there is *any* failure mode in
> > swsusp
> > that can result in this behavior.
>
> I of course won't say that this cannot happen, but by design, the
> swsusp
> signature is invalidated even before reading the image, so
> theoretically
> it should not happen.

Yes, I'd seen that happen on earlier swsusps, so I was quite suprised
when it blew up like this.

Perhaps the image should be more rigorously checked?  I'm wishing that
it would verify that the header and the image matched, after it finishes
reading the image.  For example, computing the hash

MD5(header || image)     (|| denotes "concatenate" in crypto pseudocode.)

and storing that hash in a final trailing block.  Additionally, of
course, as soon as the resume has read the image it should overwrite the
header; and the header should include jiffies or something along those
lines to ensure that it won't accidentally have the same contents as the
previous image's header.

The hash doesn't have to be MD5; even a CRC should suffice I think...

-andy