[lkml]   [2015]   [Oct]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH -mm 2/3] nbd: nbd_thread_recv: remove the buggy kernel_dequeue_signal()
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

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.


 \ /
  Last update: 2015-10-28 16:21    [W:0.085 / U:1.292 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site