From: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
To: Bastian Blank <bastian@waldi.eu.org>,
oleg@redhat.com, ebiederm@xmission.com, roland@redhat.com,
containers@lists.osdl.org, linux-kernel@vger.kernel.org,
xemul@openvz.org
Subject: Re: [RFC][PATCH 3/5] Determine if sender is from ancestor ns
Date: Mon, 1 Dec 2008 12:15:06 -0800 [thread overview]
Message-ID: <20081201201506.GB12493@us.ibm.com> (raw)
In-Reply-To: <20081127010101.GA13545@wavehammer.waldi.eu.org>
Bastian Blank [bastian@waldi.eu.org] wrote:
| On Tue, Nov 25, 2008 at 07:46:11PM -0800, Sukadev Bhattiprolu wrote:
| > +#ifdef CONFIG_PID_NS
| > +#define SIG_FROM_USER INT_MIN /* MSB */
|
| Is it really a wise idea to mix this into the signal number?
We have been trying to make this least intrusive and iiuc, extending
siginfo_t is not easy.
| Also this definition looks odd. If you want the highest bit, you should
| mention this explicitely with 1U<<31.
I think that should be fine.
|
| If I see this correctly this information is already covered in si_code
| with SI_USER and SI_TKILL. SI_KERNEL is used for explicit kernel
| generated signals.
Yes, but si_code from sys_rt_sigqueueinfo() cannot be trusted. To be sure
we would have to check for "si_code < 0", but that would include cases like
SI_ASYNCIO which can come from interrupt/work-queues. which would require
more complex checks to safely compute namespace of sender.
IOW, we need to find the namespace of the sender only if the sender is
a user process. If signal is originating from kernel, safely checking
namespace becomes more complex.
Yes, current approach is somewhat hacky. We tried other approaches
before and they were either intrusive or required non-trivial changes
to semantics of signals to global init or both.
|
| > +static inline int siginfo_from_ancestor_ns(struct task_struct *t,
| > + siginfo_t *info)
| > +{
| > + if (!is_si_special(info) && (info->si_signo & SIG_FROM_USER)) {
| > + /* if t can't see us we are from parent ns */
|
| What?
I assume your question is about the comment :-)
Yes, a process can see all its descendants and processes in descendant
namespaces. But it can only see its ancestors upto the most recent
CLONE_NEWPID. (kind of like chroot in filesystems). So if receiver
can't see sender, sender must be an ancestor.
|
| > static int send_signal(int sig, struct siginfo *info, struct task_struct *t,
| > int group)
| > {
| > struct sigpending *pending;
| > struct sigqueue *q;
| > + int from_ancestor_ns;
| >
| > trace_sched_signal_send(sig, t);
| >
| > + from_ancestor_ns = siginfo_from_ancestor_ns(t, info);
| > +
|
| This is not used at all here?
Yes, its used in next patch.
next prev parent reply other threads:[~2008-12-01 20:15 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-26 3:42 [RFC][PATCH 0/5] Container init signal semantics Sukadev Bhattiprolu
2008-11-26 3:44 ` [RFC][PATCH 1/5] pid: Implement ns_of_pid Sukadev Bhattiprolu
2008-11-27 1:19 ` Bastian Blank
2008-12-01 20:24 ` Sukadev Bhattiprolu
2008-12-02 11:58 ` Bastian Blank
2008-12-02 22:12 ` Sukadev Bhattiprolu
2008-12-03 0:34 ` Valdis.Kletnieks
2008-11-26 3:45 ` [RFC][PATCH 2/5] pid: Generalize task_active_pid_ns Sukadev Bhattiprolu
2008-11-27 1:17 ` Bastian Blank
2008-11-27 21:19 ` Greg Kurz
2008-12-01 21:15 ` Sukadev Bhattiprolu
2008-12-02 11:57 ` Bastian Blank
2008-12-03 7:41 ` Sukadev Bhattiprolu
2008-12-04 12:58 ` Bastian Blank
2008-11-27 13:09 ` Nadia Derbey
2008-12-01 20:38 ` Sukadev Bhattiprolu
2008-11-26 3:46 ` [RFC][PATCH 3/5] Determine if sender is from ancestor ns Sukadev Bhattiprolu
2008-11-27 1:01 ` Bastian Blank
2008-12-01 20:15 ` Sukadev Bhattiprolu [this message]
2008-12-02 11:48 ` Bastian Blank
2008-12-02 19:59 ` Sukadev Bhattiprolu
2008-12-04 12:45 ` [RFC][PATCH 3/5] Determine if sender is from ancestor ns+ Bastian Blank
2008-12-02 3:07 ` [RFC][PATCH 3/5] Determine if sender is from ancestor ns Roland McGrath
2008-12-04 1:06 ` Roland McGrath
2008-12-09 3:22 ` Sukadev Bhattiprolu
2008-11-26 3:46 ` [RFC][PATCH 4/5] Protect cinit from fatal signals Sukadev Bhattiprolu
2008-11-27 1:07 ` Bastian Blank
2008-12-01 20:21 ` Sukadev Bhattiprolu
2008-12-02 12:06 ` Bastian Blank
2008-12-02 20:51 ` Sukadev Bhattiprolu
2008-12-04 12:52 ` Bastian Blank
2008-12-04 18:58 ` Sukadev Bhattiprolu
2008-11-26 3:46 ` [RFC][PATCH 5/5] Clear si_pid for signal from ancestor ns 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=20081201201506.GB12493@us.ibm.com \
--to=sukadev@linux.vnet.ibm.com \
--cc=bastian@waldi.eu.org \
--cc=containers@lists.osdl.org \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=roland@redhat.com \
--cc=xemul@openvz.org \
/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