From: Oleg Nesterov <oleg@redhat.com>
To: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Cc: ebiederm@xmission.com, roland@redhat.com, bastian@waldi.eu.org,
daniel@hozac.com, xemul@openvz.org, containers@lists.osdl.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/6][v5] Define siginfo_from_ancestor_ns()
Date: Mon, 5 Jan 2009 15:33:34 +0100 [thread overview]
Message-ID: <20090105143334.GD3313@redhat.com> (raw)
In-Reply-To: <20081227205222.GB27337@us.ibm.com>
Really minor nit, just noticed...
On 12/27, Sukadev Bhattiprolu wrote:
>
> +static inline int siginfo_from_ancestor_ns(struct task_struct *t,
> + siginfo_t *info)
> +{
> + struct pid_namespace *ns;
> +
> + /*
> + * Ensure signal is from user-space before checking pid namespace.
> + * (We maybe called from interrupt context and dereferencing
> + * pid namespace would be safe).
> + */
> + if (siginfo_from_user(info)) {
I can't parse the comment above, and imho it is confusing and
misleading. We can dereference pid namespace even in interrupt
context.
Also, the comment looks as if "when siginfo_from_user() is false,
it is not safe/possible to derive from_ancestor_ns". This is not
true, in that case we know that from_ancestor_ns must be false.
from_ancestor_ns == T means the signal was sent from the user
space, and it was sent to the task in the sub-namespace, so it
is clear why we check siginfo_from_user().
Oleg.
next prev parent reply other threads:[~2009-01-05 14:33 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-27 20:46 [PATCH 0/6][v5]: Container-init signal semantics Sukadev Bhattiprolu
[not found] ` <20081227204658.GA27197-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2008-12-27 20:49 ` [PATCH 1/6][v5] Remove 'handler' parameter to tracehook functions Sukadev Bhattiprolu
2008-12-27 20:49 ` Sukadev Bhattiprolu
2008-12-27 20:51 ` [PATCH 2/6][v5] Protect init from unwanted signals more Sukadev Bhattiprolu
2008-12-27 20:52 ` [PATCH 3/6][v5] Define siginfo_from_ancestor_ns() Sukadev Bhattiprolu
2008-12-31 0:12 ` Roland McGrath
[not found] ` <20081227205222.GB27337-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-01-05 12:42 ` Oleg Nesterov
2009-01-05 12:42 ` Oleg Nesterov
2009-01-05 14:33 ` Oleg Nesterov [this message]
2008-12-27 20:53 ` [PATCH 4/6][v5] Protect cinit from unblocked SIG_DFL signals Sukadev Bhattiprolu
2008-12-31 0:19 ` Roland McGrath
[not found] ` <20081231001942.F35E2FC278-nL1rrgvulkc2UH6IwYuUx0EOCMrvLtNR@public.gmane.org>
2009-01-05 13:24 ` Oleg Nesterov
2009-01-05 13:24 ` Oleg Nesterov
2008-12-27 20:54 ` [PATCH 5/6][v5] Protect cinit from blocked fatal signals Sukadev Bhattiprolu
2009-01-05 15:16 ` Oleg Nesterov
2008-12-27 20:55 ` [PATCH 6/6][v5] SI_USER: Masquerade si_pid when crossing pid ns boundary 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=20090105143334.GD3313@redhat.com \
--to=oleg@redhat.com \
--cc=bastian@waldi.eu.org \
--cc=containers@lists.osdl.org \
--cc=daniel@hozac.com \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
--cc=roland@redhat.com \
--cc=sukadev@linux.vnet.ibm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.