On Tue, 17 Jul 2007 david@xxxxxxx wrote: > On Tue, 17 Jul 2007, Alan Stern wrote: > > > On Tue, 17 Jul 2007 david@xxxxxxx wrote: > > > >>> But what about the freezer? The original reason for using kexec was to > >>> avoid the need for the freezer. With no freezer, while the original > >>> kernel is busy powering down its devices, user tasks will be free to > >>> carry out I/O -- which will make the memory snapshot inconsistent with > >>> the on-disk data structures. > >> > >> no, user tasks just don't get scheduled during shutdown. > > > > But a user task may be holding a lock which is needed for putting some > > device into low-power mode. It can't release that lock if it doesn't > > get scheduled. > > then you can't suspend that box. if you schedule it, it could get another > lock (or another process gets another lock) > > if you can't power down or put hardware into low-power mode without the > approval of userspace, you are in serious trouble. You don't seem to appreciate the issues involved here. Part of the justification for the freezer is that it doesn't need userspace approval and it freezes tasks at controlled points where they don't hold any locks. Never mind. It seems clear that this approach will suffer the same drawback as the proposal for removing the freezer from the suspend-to-RAM pathway. Namely, device drivers will have to be changed to prevent user I/O requests from proceeding while devices are supposed to be quiescent or in a low-power state. If a driver fails to handle this properly, its device could be reactivated in order to service a user request before the memory snapshot is made. This could easily ruin the snapshot. Alan Stern _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
