linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
To: Daniel Lezcano <dlezcano@fr.ibm.com>
Cc: Sukadev Bhattiprolu <sukadev@us.ibm.com>,
	Linux Containers <containers@lists.osdl.org>,
	oleg@redhat.com, roland@redhat.com, linux-kernel@vger.kernel.org
Subject: Re: pidns : PR_SET_PDEATHSIG + SIGKILL regression
Date: Sat, 3 Oct 2009 10:10:29 -0700	[thread overview]
Message-ID: <20091003171029.GA30442@us.ibm.com> (raw)
In-Reply-To: <4AC608BE.9020805@fr.ibm.com>

[-- Attachment #1: Type: text/plain, Size: 2489 bytes --]


Cc Oleg and Roland and moving discussion to LKML.

Daniel Lezcano [dlezcano@fr.ibm.com] wrote:
> Hi,
>
> I noticed a changed behaviour with the PR_SET_PDEATHSIG and SIGKILL  
> between different kernel versions.
>
> With a kernel 2.6.27.21-78.2.41.fc9.x86_64, the SIGKILL signal is  
> delivered to the child process when the parent dies but with a 2.6.31  
> kernel version that don't happen.
>
> The program below shows the problem. I remember there was were some  
> modifications about not killing the init process of the container from  
> inside, but in this case, that happens _conceptually_ from outside.  
> Keeping this feature is very important to be able to wipe out the  
> container when the parent process of the container dies.

(Test case moved to attachment).

---
Container init must not be immune to signals from parent. But as pointed
out by Daniel Lezcano: 

https://lists.linux-foundation.org/pipermail/containers/2009-October/021121.html

container-init is currently immune to signals from parent, if sent via
->pdeath_signal. This is because the siginfo for ->pdeath_signal is set to
SEND_SIG_NOINFO which is considered special.

This quick patch passes in siginfo explicitly (just like we do when sending
SIGCHLD to parent) and seems to fix the problem. Not though sure if
->pdeath_signal needs to be 'is_si_special()'.

Changelog [v2]:
	- [Oleg Nesterov] Add missing initializer, ->si_code = SI_USER
	- [Sukadev Bhattiprolu] Use 'tgid' of parent instead of 'pid'.

---
 kernel/exit.c |   16 ++++++++++++++--
 1 file changed, 14 insertions(+), 2 deletions(-)

Index: linux-2.6/kernel/exit.c
===================================================================
--- linux-2.6.orig/kernel/exit.c	2009-10-02 19:23:00.000000000 -0700
+++ linux-2.6/kernel/exit.c	2009-10-03 10:02:42.000000000 -0700
@@ -738,8 +738,20 @@ static struct task_struct *find_new_reap
 static void reparent_thread(struct task_struct *father, struct task_struct *p,
 				struct list_head *dead)
 {
-	if (p->pdeath_signal)
-		group_send_sig_info(p->pdeath_signal, SEND_SIG_NOINFO, p);
+	if (p->pdeath_signal) {
+		struct siginfo info;
+
+		info.si_code = SI_USER;
+		info.si_signo = p->pdeath_signal;
+		info.si_errno = 0;
+
+		rcu_read_lock();
+		info.si_pid = task_tgid_nr_ns(father, task_active_pid_ns(p));
+		info.si_uid = __task_cred(father)->uid;
+		rcu_read_unlock();
+
+		group_send_sig_info(p->pdeath_signal, &info, p);
+	}
 
 	list_move_tail(&p->sibling, &p->real_parent->children);
 

[-- Attachment #2: pdeath.c --]
[-- Type: text/x-csrc, Size: 931 bytes --]

#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <sys/prctl.h>
#include <sys/param.h>
#include <sys/poll.h>
#include <signal.h>
#include <sched.h>

#ifndef CLONE_NEWPID
#  define CLONE_NEWPID            0x20000000
#endif

int child(void *arg)
{
    if (prctl(PR_SET_PDEATHSIG, SIGKILL, 0, 0, 0)) {
        perror("prctl");
        return -1;
    }

    sleep(3);
    printf("I should have gone with my parent\n");
    return -1;
}

pid_t clonens(int (*fn)(void *), void *arg, int flags)
{
    long stack_size = sysconf(_SC_PAGESIZE);
     void *stack = alloca(stack_size) + stack_size;
    return clone(fn, stack, flags | SIGCHLD, arg);
}

int main(int argc, char *argv[])
{
    pid_t pid;

    pid = clonens(child, NULL, CLONE_NEWNS|CLONE_NEWPID);
    if (pid < 0) {
        perror("clone");
        return -1;
    }

    /* let the child to be ready, ugly but simple code */
    sleep(1);
    
    return 0;
}

       reply	other threads:[~2009-10-03 17:11 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <4AC608BE.9020805@fr.ibm.com>
2009-10-03 17:10 ` Sukadev Bhattiprolu [this message]
2009-10-04  2:18   ` [PATCH 0/4] Was: pidns : PR_SET_PDEATHSIG + SIGKILL regression Oleg Nesterov
2009-10-04  2:19     ` [PATCH 1/4] signals: SEND_SIG_NOINFO should be considered as SI_FROMUSER() Oleg Nesterov
2009-10-04  2:25       ` Oleg Nesterov
2009-10-05 17:58       ` Sukadev Bhattiprolu
2009-10-05 18:39         ` Oleg Nesterov
2009-10-06  0:09       ` Sukadev Bhattiprolu
2009-10-06  7:31       ` Roland McGrath
2009-10-06 13:37         ` Oleg Nesterov
2009-10-06 17:57           ` Roland McGrath
2009-10-07 11:30             ` Oleg Nesterov
2009-10-08  1:57               ` Roland McGrath
2009-10-04  2:19     ` [PATCH 2/4] signals: send_signal: use si_fromuser() to detect from_ancestor_ns Oleg Nesterov
2009-10-05 18:12       ` Sukadev Bhattiprolu
2009-10-05 18:25         ` Oleg Nesterov
2009-10-05 19:37           ` Sukadev Bhattiprolu
2009-10-05 19:44             ` Oleg Nesterov
2009-10-05 19:55               ` Oleg Nesterov
2009-10-06  0:06               ` Sukadev Bhattiprolu
2009-10-06  1:09                 ` Oleg Nesterov
2009-10-06  2:34                   ` Sukadev Bhattiprolu
2009-10-06 13:18                     ` Oleg Nesterov
2009-10-06 18:01                       ` Roland McGrath
2009-10-06  0:16       ` Sukadev Bhattiprolu
2009-10-04  2:20     ` [PATCH 3/4] signals: cosmetic, collect_signal: use SI_USER Oleg Nesterov
2009-10-05 18:03       ` Sukadev Bhattiprolu
2009-10-04  2:20     ` [PATCH 4/4] signals: kill force_sig_specific() Oleg Nesterov
2009-10-05 18:04       ` Sukadev Bhattiprolu

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=20091003171029.GA30442@us.ibm.com \
    --to=sukadev@linux.vnet.ibm.com \
    --cc=containers@lists.osdl.org \
    --cc=dlezcano@fr.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleg@redhat.com \
    --cc=roland@redhat.com \
    --cc=sukadev@us.ibm.com \
    /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).