Serge E. Hallyn wrote: > (This is a patch against the checkpoint/restart kernel tree at > http://git.ncl.cs.columbia.edu/?p=linux-cr.git;a=shortlog;h=refs/heads/ckpt-v19-rc2.9) > > On x86, do_signal() leaves -516 in eax while it freezes, which > sys_restart() can use to detect that it should restart the > syscall which was interrupted by a signal (or the freezer). > > On s390, gprs[2] gets tweaked to -EINTR (-4) instead, leaving > us no reliable way to tell whether should be restarted. If the > task is checkpointed here and then restarted, then the last part > of do_signal() won't be done, and the interrupted syscall won't > be restarted. > > This patch defines TIF_RESTARTBLOCK as a thread flag showing that > the thread expects to be frozen while kicked out of a restartable > syscall by a signal. > > The TIF_RESTARTBLOCK flag is only set for the duration of the > get get_signal_to_deliver() which is where the task may get > frozen. We also set it in sys_restart() if the checkpointed task > had had TIF_RESTARTBLOCK set. It will get cleared if upon exiting > sys_restart() we jump to sysc_sigpending. If instead we jump back > to do_signal(), then TIF_RESTARTBLOCK will stay set again until > after get_signal_to_deliver() so that if it immediately freezes and > is re-checkpointed, the resulting second checkpoint image again > will have TIF_RESTARTBLOCK set. Two comments: 1) This note will be lost once we fold this patch into a clean patchset. Can you please make it part of the code ? 2) Maybe I'm missing something, but I'm not convinced. Can you elaborate on why this is correct in different cases ? Also, in particular with respect to the post-signal-sent snippet in the signal handling code: if (retval == -ERESTART_RESTARTBLOCK && regs->psw.addr == continue_addr) { regs->gprs[2] = __NR_restart_syscall; set_thread_flag(TIF_RESTART_SVC); } Would it do what you expect after a restart ? (restart modifies the psw.addr) Oren. -- To unsubscribe from this list: send the line "unsubscribe linux-s390" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
