Messages in this thread | | | Subject | Re: [Devel] Re: [PATCH 08/10] Introduce functions to restart a process | From | Dave Hansen <> | Date | Thu, 23 Oct 2008 06:57:57 -0700 |
| |
On Thu, 2008-10-23 at 13:00 +0400, Andrey Mirkin wrote: > > > >>> It is not related to the freezer code actually. > > >>> That is needed to restart syscalls. Right now I don't have a code in my > > >>> patchset which restarts a syscall, but later I plan to add it. > > >>> In OpenVZ checkpointing we restart syscalls if process was caught in > > >>> syscall during checkpointing. > > >> > > >> Do you checkpoint uninterruptible syscalls as well? If only > > >> interruptible syscalls are checkpointed, I'd say that either this > > >> syscall uses ERESTARTSYS or ERESTART_RESTARTBLOCK, and then signal > > >> handling code already does the trick, or this syscall does not restart > > >> itself when interrupted, and well, this is life, userspace just sees > > >> -EINTR, which is allowed by the syscall spec. > > >> Actually this is how we checkpoint/migrate tasks in interruptible > > >> syscalls in Kerrighed and this works. > > > > > > We checkpoint only interruptible syscalls. Some syscalls do not restart > > > themself, that is why after restarting a process we restart syscall to > > > complete it. > > > > Can you please elaborate on this ? I don't recall having had issues > > with that. > > Right now in 2.6.18 kernel we restarts in such a way pause, rt_sigtimedwait > and futex syscalls. Recently futex syscall was reworked and we will not need > such hooks for it.
Could you elaborate on this a bit?
If the futex syscall was reworked, perhaps we can do the same for rt_sigtimedwait() and get rid of this code completely.
-- Dave
| |