Linux Container Development
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Sukadev Bhattiprolu
	<sukadev-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
Cc: bastian-yyjItF7Rl6lg9hUCZPvPmw@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@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 6/6][v3] Protect cinit from blocked fatal signals
Date: Tue, 23 Dec 2008 01:03:56 +0100	[thread overview]
Message-ID: <20081223000356.GB7279@redhat.com> (raw)
In-Reply-To: <20081222233855.GA13079-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>

On 12/22, Sukadev Bhattiprolu wrote:
>
> Oleg Nesterov [oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org] wrote:
> | > @@ -1907,9 +1943,10 @@ relock:
> | >
> | >  		/*
> | >  		 * Global init gets no signals it doesn't want.
> | > +		 * Container-init gets no signals it doesn't want from same
> | > +		 * container.
> | >  		 */
> | > -		if (unlikely(signal->flags & SIGNAL_UNKILLABLE) &&
> | > -		    !signal_group_exit(signal))
> | > +		if (sig_unkillable(signal, signr) && !signal_group_exit(signal))
> | >  			continue;
> | 
> | Again, I do not understand why do we need SIGNAL_UNKILLABLE_FROM_NS.
> | 
> | I thought about the change in get_signal_to_deliver() during the
> | previous discussion, and I think what we need is:
> | 
> | 		if (unlikely(signal->flags & SIGNAL_UNKILLABLE) &&
> | 		    !sig_kernel_only(sig))
> | 			continue;
> | 
> | and this was yet another reason for "protect init from unwanted signals more".
> 
> I was trying to avoid the clearing of the SIGNAL_UNKILLABLE in
> send_signal() that we had last time.

Well, my plan was to simplify the first series of patches as much
as possible, then I thought we can change get_signal_to_deliver().

But now I tend to agree, we should not clear SIGNAL_UNKILLABLE when
we send the signal, and we should pass same_ns/from_parent_ns to
prepare_signal() from the start. This way is more "clean".

> But yes, you are right. I even had a BUG_ON() to confirm SIGKILL/SIGSTOP
> will never happen for global-init :-). If so, SIGKLL/SIGSTOP to an init
> can come only from parent ns.
>
> So, yes, we can drop this flag.

Great!

Oleg.

  parent reply	other threads:[~2008-12-23  0:03 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-21  0:51 [RFC][PATCH 0/6][v3] Container-init signal semantics Sukadev Bhattiprolu
2008-12-21  0:52 ` [RFC][PATCH 1/6][v3] Remove 'handler' parameter to tracehook functions Sukadev Bhattiprolu
2008-12-23 19:30   ` Roland McGrath
2008-12-21  0:53 ` [RFC][PATCH 2/6][v3] Protect init from unwanted signals more Sukadev Bhattiprolu
     [not found]   ` <20081221005319.GB5025-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2008-12-23 19:31     ` Roland McGrath
     [not found] ` <20081221005106.GA4912-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2008-12-21  0:53   ` [RFC][PATCH 3/6][v3] Define/set SIGNAL_UNKILLABLE_FROM_NS Sukadev Bhattiprolu
2008-12-21  0:54 ` [RFC][PATCH 4/6][v3] Define siginfo_from_ancestor_ns() Sukadev Bhattiprolu
2008-12-22 22:26   ` Oleg Nesterov
     [not found]     ` <20081222222604.GA1536-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2008-12-22 23:01       ` Oleg Nesterov
2008-12-22 23:58         ` Sukadev Bhattiprolu
2008-12-23  0:22           ` Oleg Nesterov
     [not found]             ` <20081223002215.GA7984-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2008-12-23  0:32               ` Eric W. Biederman
2008-12-23  4:47                 ` Sukadev Bhattiprolu
2008-12-22 23:45     ` Sukadev Bhattiprolu
2008-12-22 23:54       ` Oleg Nesterov
2008-12-21  0:54 ` [RFC][PATCH 5/6][v3] Protect cinit from unblocked SIG_DFL signals Sukadev Bhattiprolu
2008-12-22 22:46   ` Oleg Nesterov
2008-12-21  0:55 ` [RFC][PATCH 6/6][v3] Protect cinit from blocked fatal signals Sukadev Bhattiprolu
     [not found]   ` <20081221005529.GF5025-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2008-12-22 22:58     ` Oleg Nesterov
2008-12-22 23:38       ` Sukadev Bhattiprolu
     [not found]         ` <20081222233855.GA13079-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2008-12-23  0:03           ` Oleg Nesterov [this message]
2008-12-22 10:55 ` [RFC][PATCH 0/6][v3] Container-init signal semantics Eric W. Biederman
2008-12-22 19:47   ` Sukadev Bhattiprolu
     [not found]     ` <20081222194737.GC9085-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2008-12-23  0:27       ` Eric W. Biederman
2008-12-23  2:12         ` Sukadev Bhattiprolu
2008-12-23 16:51 ` Serge E. Hallyn

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=20081223000356.GB7279@redhat.com \
    --to=oleg-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
    --cc=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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox