Re: resuming swsusp twice

From: Andy Isaacson (adi_at_hexapodia.org)
Date: 07/14/05

  • Next message: yhlu: "NUMA support for dual core Opteron" 
    Date:	Thu, 14 Jul 2005 10:54:47 -0700
To: Stefan Seyfried <seife@suse.de>

    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
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: yhlu: "NUMA support for dual core Opteron"