Messages in this thread | | | Date | Mon, 26 Nov 2018 22:38:00 -0800 | From | Andrei Vagin <> | Subject | Re: [PATCH] ptrace: take into account saved_sigmask in PTRACE_{GET,SET}SIGMASK |
| |
On Thu, Nov 22, 2018 at 12:47:52PM +0100, Oleg Nesterov wrote: > On 11/19, Andrei Vagin wrote: > > > > case PTRACE_SETSIGMASK: { > > sigset_t new_set; > > @@ -962,6 +971,8 @@ int ptrace_request(struct task_struct *child, long request, > > child->blocked = new_set; > > spin_unlock_irq(&child->sighand->siglock); > > > > + clear_tsk_restore_sigmask(child); > > + > > I am not sure I understand this change... > > I forgot everything I knew about criu, but iiuc PTRACE_SETSIGMASK is used > at "restore" time, doesn't this mean that TIF_RESTORE_SIGMASK/restore_sigmask > can not be set?
PTRACE_SETSIGMASK isn't used on restore. On restore, criu generates sigframe and calls sigreturn to restore registers, fpu state, sigmask and resume a process. When the kernel constructs a signal frame, it calls sigmask_to_save() to get a process signal mask. With this patch, PTRACE_GETSIGMASK returns the same signal mask what is returned by sigmask_to_save().
In CRIU, we don't need to set TIF_RESTORE_SIGMASK, because all processes are dumped when they are in user-space.
> > IOW, could you please explain how PTRACE_SETSIGMASK should be used, and why > it doesn't do something like >
CRIU uses PTRACE_SETSIGMASK when it injects a parasite code into a target process. In this case, we have to be sure that when the process is resumed by PTRACE_CONT, it will not start handling signals and executing signal handlers.
> if (test_tsk_restore_sigmask(child)) > child->saved_sigmask = new_set; > else > child->blocked = new_set; > > which looks symmetrical to PTRACE_GETSIGMASK?
If we set child->saved_sigmask, the child can start handling signals which are not set in child->blocked.
> > Oleg. >
| |