Re: swsusp: move resume before mounting root [diff against vanilla 2.4.9]

Pavel Machek (pavel@suse.cz)
Fri, 28 Sep 2001 22:40:01 +0200


Hi!

> > I can't do that: open deleted files.
>
> Tough luck. Either use the same hack as NFS, or have such files
> return -EIO for all operations and give SIGBUS for mappings.
> Maybe just refuse to suspend when there are open deleted files.
> Oh, just create a name in the filesystem root and use that.
> Something like ".8fe4a979.swsusp" would be fine. Whatever!

...and break locking and similar stuff. NFS is not as good as local
filesystem.

> >> NFS faces. Between the suspend and resume, filesystems may be
> >> modified in arbitrary ways.
> >
> > No, you don't want to do that. This is swsusp package, meant to
> > replace suspend-to-disk on your notebook. If you choose random
> > notebook, it will allow you to suspend to disk, but not to suspend,
> > boot X, poweron, boot Y, reboot, boot X.
> >
> > If you do what you described, you'll corrupt your filesystem. It is
> > designed that way.
>
> Not "If", but "When". Somebody has already posted a report of
> doing exactly that, by accident, with a 3-month-old suspension.
> The filesystems were destroyed.
>
> Right now, swsusp is a serious hazard.

That's why its called experimental ;-).

Currently we have "SWSUSP" signature, SWAP-FILE gets replaced with
SWSUSP on suspend, and SWAP-FILE is written back on resume. That way,
you can not resume two times from one image.

Additional safety measure could be added: on every swapon, check if
"SWSUSP" is there, and replace it with "SWAP-FILE" if so. (Currently
it says -EINVAL). That should make it pretty safe.

Of course, you'll still be able to shoot yourself in the foot even
with added "security". Just don't do it, then.
Pavel

-- 
I'm pavel@ucw.cz. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at discuss@linmodems.org
-
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/