From: Oleg Nesterov <oleg@redhat.com>
To: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Cc: ebiederm@xmission.com, daniel@hozac.com, xemul@openvz.org,
containers@lists.osdl.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH][v2] Define/use siginfo_from_ancestor_ns()
Date: Mon, 24 Nov 2008 00:10:14 +0100 [thread overview]
Message-ID: <20081123231014.GA2424@redhat.com> (raw)
In-Reply-To: <20081119012207.GA19092@us.ibm.com>
On 11/18, Sukadev Bhattiprolu wrote:
>
> |
> | > +static inline int siginfo_from_ancestor_ns(siginfo_t *info)
> | > +{
> | > + return SI_FROMUSER(info) && (info->si_pid == 0);
> | > +}
> |
> | Yes, this is problem... I doubt we can rely on !si_pid here.
> | More on this later.
>
> BTW, rather than clearing SIG_FROM_USER in send_signal(), can we
> keep it till we dequeue the signal ? Yes, collect_signal() would
> need to consider this flag. But when we dequeue, we can note that
> it was from user and use that in the siginfo_from_ancestor() ?
Yes! I thought about this too. As a last resort this should work
afaics. But we should be carefull, we have to fix rm_from_queue_full()
for example as well.
Another note. We can split SIG_FROM_USER (if we are going to use this
hack) into 2 flags: SIG_KILL_SUB_NS and SIG_MANGLE_SI_PID. We can
even put "struct pid *pid" into si_signo along with these bits if
we find some strange user which sends the signal on behalve of
the different task.
But personally, I'd prefer to make 3 simple patches for the start.
Then we can continue with these complications if needed. Sukadev,
please feel free to disagree with me. I am just trying to make
the first step reviewable and simple. No changes on dequeue path,
no -ENOMEM in send_signal().
1. Introduce SIG_FROM_USER (or whatever). Basically, the patch I
sent. Except I'd relly like to see this code under CONFIG_
just for documentation, but please feel free to ignore.
So, with this patch send_signal() has "bool from_ancestor", which
is not used so far. And we the fixup code after copy_siginfo()
which clears the flags, or better yet just sets .si_signo = sig.
2. Now we change send_signal()
+ if (from_ancestor && sig == SIGKILL)
+ t->signal->flags &= ~SIGNAL_UNKILLABLE;
if (!prepare_signal(...))
return;
and change copy_signal() to set SIGNAL_UNKILLABLE for
cinit.
From now cinit is protected from unwanted signals from
its namespace, and the parent can always kill it with
SIGKILL.
Actually, I think this is enough to solve most problems,
the further changes can be discussed later. OK, the only
"real" problem is SIGSTOP, afaics. This looks solveable.
3. mangle .si_pid in send_signal(). Again, it is not clear
what should we do with sys_rt_sigqueueinfo(), but there
is no "obviously right" solution.
And I am really sorry for delay.
Oleg.
next prev parent reply other threads:[~2008-11-23 23:10 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-15 21:21 [RFC][PATCH][v2] Define/use siginfo_from_ancestor_ns() Sukadev Bhattiprolu
2008-11-18 17:53 ` Oleg Nesterov
2008-11-18 18:37 ` Sukadev Bhattiprolu
2008-11-19 1:22 ` Sukadev Bhattiprolu
2008-11-23 23:10 ` Oleg Nesterov [this message]
2008-11-26 3:16 ` Sukadev Bhattiprolu
2008-11-26 17:44 ` Sukadev Bhattiprolu
2008-11-19 2:28 ` 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=20081123231014.GA2424@redhat.com \
--to=oleg@redhat.com \
--cc=containers@lists.osdl.org \
--cc=daniel@hozac.com \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
--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.