On 10/26, Markus Pargmann wrote: > > Hi Oleg, > > On Sun, Oct 25, 2015 at 04:26:39PM +0100, Oleg Nesterov wrote: > > nbd_thread_recv() is called by userspace, it is very wrong to dequeue > > and throw out a signal. > > This signal handling for a userspace process is implicitly implemented > for several years already through the timeout handling. This is nothing > new and could potentially break userspace if someone disconnects NBD > using the kill command. As we expose the appropriate PID of the process > as well this is possible to be used in an init script. > > So I am not sure about this patch yet.
I strongly believe this kernel_dequeue_signal() must die, it is very wrong and I can't even enumerate all problems. And why do you want it? Probably to "hide" the SIGKILL sent while this process was exposed as ->task_recv. This can not work even in the simplest case when this process is single-threaded. kernel_dequeue_signal() won't clear SIGNAL_GROUP_EXIT set by SIGKILL, it won't remove SIGKILL from shared_pending if it was sent by the kill command. Note also that SIGKILL can be sent from another thread which does exec/group_exit/coredump. In this case the state of this thread group will be very wrong after kernel_dequeue_signal() removes SIGKILL from task_struct->pending. Finally. We can not even know which signal we are going to dequeue and throw out. Say, it can be SIGCHLD or any other unrelated signal. No, this can't be right. Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
