"Rafael J. Wysocki" <rjw@xxxxxxx> writes: [snip] >> Or add a small bit of infrastructure that errors writes at make_request >> if you don't have a magic "i am a direct block device write from >> userspace" flag on the bio. >> >> The hibernate may fail, but you don't corrupt the media. >> >> If you don't get the image out, resume back to the "this is resume" >> instead of the power-down path. > Well, I don't think that is much prettier than the freezer ... It seems that a better solution to the "how do we write to a file on an in-use partition" has been suggested, which also handles swap partitions and swap files, and does not require mounting filesystems, so it seems that the filesystem issue need not be considered. [snip] > No. I'm saying that when you go back from the image-saving kernel to the > hibernated kernel, you need to make sure that no task will cause any > filesystem's on-disk state to be actually updated. If you can't make such > a guarantee, you just can't do that. > With the current state of the drivers, it's not doable without the > freezer. It seems that it should be feasible to fix the drivers so that 1. they can be taken from normal state to quiesced state without requiring the freezer; 2. they can be taken from normal state to low power state without requiring the freezer; 3. they can be taken from quiesced state to low power state without requiring the freezer. In the particular, it seems that it should be possible to do (3) without needing to schedule tasks. It seems likely that (2) may in fact be almost exactly the same as, or at least similar to, (1) followed by (3), at least for many drivers. (1) is required by the kexec hibernate approach even ignoring suspend to both or S4. (2) is required for suspend to ram without the freezer, which seems to be desired anyway. [snip] -- Jeremy Maitin-Shepard _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
