From: Bastian Blank <bastian-yyjItF7Rl6lg9hUCZPvPmw@public.gmane.org>
To: Sukadev Bhattiprolu
<sukadev-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org,
containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org,
roland-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
xemul-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org
Subject: Re: [RFC][PATCH 3/5] Determine if sender is from ancestor ns
Date: Thu, 27 Nov 2008 02:01:01 +0100 [thread overview]
Message-ID: <20081127010101.GA13545@wavehammer.waldi.eu.org> (raw)
In-Reply-To: <20081126034611.GC23238-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
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? Also this
definition looks odd. If you want the highest bit, you should mention
this explicitely with 1U<<31.
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.
> +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?
> 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?
Bastian
--
Those who hate and fight must stop themselves -- otherwise it is not stopped.
-- Spock, "Day of the Dove", stardate unknown
WARNING: multiple messages have this Message-ID (diff)
From: Bastian Blank <bastian@waldi.eu.org>
To: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Cc: 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: Thu, 27 Nov 2008 02:01:01 +0100 [thread overview]
Message-ID: <20081127010101.GA13545@wavehammer.waldi.eu.org> (raw)
In-Reply-To: <20081126034611.GC23238@us.ibm.com>
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? Also this
definition looks odd. If you want the highest bit, you should mention
this explicitely with 1U<<31.
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.
> +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?
> 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?
Bastian
--
Those who hate and fight must stop themselves -- otherwise it is not stopped.
-- Spock, "Day of the Dove", stardate unknown
next prev parent reply other threads:[~2008-11-27 1:01 UTC|newest]
Thread overview: 41+ 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-26 3:44 ` 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-26 3:45 ` 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-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-26 3:46 ` Sukadev Bhattiprolu
2008-12-02 3:07 ` Roland McGrath
[not found] ` <20081126034611.GC23238-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2008-11-27 1:01 ` Bastian Blank [this message]
2008-11-27 1:01 ` Bastian Blank
2008-12-01 20:15 ` Sukadev Bhattiprolu
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-04 1:06 ` [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-26 3:46 ` 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
2008-11-26 3:46 ` 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=20081127010101.GA13545@wavehammer.waldi.eu.org \
--to=bastian-yyjitf7rl6lg9huczpvpmw@public.gmane.org \
--cc=containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org \
--cc=ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=roland-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=sukadev-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org \
--cc=xemul-GEFAQzZX7r8dnm+yROfE0A@public.gmane.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.