On Tue, Nov 26, 2013 at 10:44:48AM +0100, Thomas Bächler wrote: > Am 24.11.2013 03:01, schrieb Dave Reisner: > > This solves the problem of the major:minor of devices changing between > > hibernation. It also makes initialization lazy, as we no longer need to > > explicitly wait on the device to show up (this will be taken care of by > > udevadm settle). > > > > Note that this patch drops support for tux-on-ice. As upstream > > developerment of TOI seems stalled and forever relegated to being > > maintained out of tree, I'm okay with this. > > > > Signed-off-by: Dave Reisner <[email protected]> > > --- > > So, I tested this as far as ensuring that the udev rule is generated > > correctly > > and triggers, writing the correct values into /sys/power/resume, but I can't > > actually hibernate/resume my desktop to test this (mobo firmware bug). > > Your firmware should not be involved at all in hibernation. As far as > your firmware is concerned, you shut down and reboot. >
Whatever it is, the shutdown never completes, and the reboot isn't a resume. > > If anyone who uses this hook wants to test this, please do and report back. > > I feel this approach is extremely dangerous due to the fragile state of > file systems during hibernation. > > Note that the file system must not change at all while the system is > hibernated. The kernel's internal state is saved in the hibernation > image - if the file system changed while the system was hibernated, the > on-disk and in-memory state will be inconsistent, almost guaranteeing > corruption (I have experienced this first-hand). > > Now, your new approach does not preserve the ordering: Trying to resume > from a hibernation image MUST happen BEFORE any of the hibernated > system's mounted file systems are touched. > > Now imagine the following situation: You have two hard drives, one > holding your root file system, the other holding your swap (and thus > hibernation image). Now imagine the following order of events: > > * Linux loads, starts /init > * Udev is started > * Hard drive A is detected. > * fsck is started, repairs the "dirty" root file system (and changes > on-disk structures, clears the journal, ...) Who/what triggered fsck here? Why is fsck being run before the udev event queue is flushed? > * Hard drive B is detected -> udev start the resume procedure. ... > Now, you have a casual file system corruption. This should easily be > reproducible by putting your swap on a hard drive and the root file > system on SSD. To reproduce this more reliably, but the swap on USB instead. > > This patch gets as many -1's from me as I can find. Hibernation is > dangerous for your data as it is, this patch plays russian data roulette. I can understand the USB case and how it might be bad news if you plugged in a matching resume device at some arbitrary point during normal operation, but I don't really think your earlier posted order of events paints a realistic picture of what happens in early userspace. I'll ask Harald about this -- Dracut uses a very similar mechanism (but a bit more complex/convoluted).
