[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20091004021954.GC21006@redhat.com>
Date: Sun, 4 Oct 2009 04:19:54 +0200
From: Oleg Nesterov <oleg@...hat.com>
To: Andrew Morton <akpm@...ux-foundation.org>,
Sukadev Bhattiprolu <sukadev@...ux.vnet.ibm.com>
Cc: Daniel Lezcano <dlezcano@...ibm.com>,
Sukadev Bhattiprolu <sukadev@...ibm.com>,
Linux Containers <containers@...ts.osdl.org>,
roland@...hat.com, linux-kernel@...r.kernel.org
Subject: [PATCH 2/4] signals: send_signal: use si_fromuser() to detect
from_ancestor_ns
Change send_signal() to use si_fromuser(). From now SEND_SIG_NOINFO
triggers the "from_ancestor_ns" check.
This fixes reparent_thread()->group_send_sig_info(pdeath_signal)
behaviour, before this patch send_signal() does not detect the
cross-namespace case when the child of the dying parent belongs
to the sub-namespace.
This patch can affect the behaviour of send_sig(), kill_pgrp() and
kill_pid() when the caller sends the signal to the sub-namespace
with "priv == 0" but surprisingly all callers seem to use them
correctly, including disassociate_ctty(on_exit).
Except: drivers/staging/comedi/drivers/addi-data/*.c incorrectly
use send_sig(priv => 0). But his is minor and should be fixed
anyway.
Reported-by: Daniel Lezcano <dlezcano@...ibm.com>
Signed-off-by: Oleg Nesterov <oleg@...hat.com>
---
kernel/signal.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
--- TTT_32/kernel/signal.c~FU_2_SEND_SIGNAL 2009-10-04 02:21:55.000000000 +0200
+++ TTT_32/kernel/signal.c 2009-10-04 03:09:44.000000000 +0200
@@ -928,9 +928,8 @@ static int send_signal(int sig, struct s
int from_ancestor_ns = 0;
#ifdef CONFIG_PID_NS
- if (!is_si_special(info) && SI_FROMUSER(info) &&
- task_pid_nr_ns(current, task_active_pid_ns(t)) <= 0)
- from_ancestor_ns = 1;
+ from_ancestor_ns = si_fromuser(info) &&
+ !task_pid_nr_ns(current, task_active_pid_ns(t));
#endif
return __send_signal(sig, info, t, group, from_ancestor_ns);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists