All of lore.kernel.org
 help / color / mirror / Atom feed
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.

  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.