linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Markus Pargmann <mpa@pengutronix.de>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	nbd-general@lists.sourceforge.net, linux-kernel@vger.kernel.org
Subject: Re: [PATCH -mm 2/3] nbd: nbd_thread_recv: remove the buggy kernel_dequeue_signal()
Date: Wed, 28 Oct 2015 16:53:53 +0100	[thread overview]
Message-ID: <20151028155353.GC22672@redhat.com> (raw)
In-Reply-To: <20151026074417.GE16521@pengutronix.de>

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.


  reply	other threads:[~2015-10-28 14:57 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-25 15:26 [PATCH -mm 0/3] nbd: fix/cleanup the usage of kernel_dequeue_signal() Oleg Nesterov
2015-10-25 15:26 ` [PATCH -mm 1/3] nbd: nbd_thread_send: remove the unnecessary kernel_dequeue_signal() Oleg Nesterov
2015-10-26  7:48   ` Markus Pargmann
2015-10-25 15:26 ` [PATCH -mm 2/3] nbd: nbd_thread_recv: remove the buggy kernel_dequeue_signal() Oleg Nesterov
2015-10-26  7:44   ` Markus Pargmann
2015-10-28 15:53     ` Oleg Nesterov [this message]
2015-10-25 15:26 ` [PATCH -mm 3/3] nbd: don't abuse irqsave/irqrestore while taking nbd->tasks_lock Oleg Nesterov
2015-10-26  7:50   ` Markus Pargmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20151028155353.GC22672@redhat.com \
    --to=oleg@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mpa@pengutronix.de \
    --cc=nbd-general@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).