On 08/21, Serge E. Hallyn wrote:
>
> Quoting Oleg Nesterov ([EMAIL PROTECTED]):
> > @@ -1841,14 +1865,6 @@ relock:
> > if (sig_kernel_ignore(signr)) /* Default is nothing. */
> > continue;
> >
> > - /*
> > -* Init of a pid space gets no signals
Quoting Oleg Nesterov ([EMAIL PROTECTED]):
> (Not for inclusion yet, against 2.6.23-rc2, untested)
>
> Currently, /sbin/init is protected from unhandled signals by the
> "current == child_reaper(current)" check in get_signal_to_deliver().
> This is not enough, we have multiple problems:
>
>
On 08/21, Pavel Emelyanov wrote:
>
> >+static int sig_init_ignore(struct task_struct *tsk)
> >+{
> >+// Currently this check is a bit racy with exec(),
> >+// we can _simplify_ de_thread and close the race.
> >+if (likely(!is_init(tsk->group_leader)))
> >+return 0;
> >+
> >+
On 08/21, [EMAIL PROTECTED] wrote:
>
> I am still reviewing this patch and will try to plug in the multiple
> pid ns code and play with it some more in the next couple of days.
Thanks!
> But am curious why we need the in_interrupt() check and that too only
> for the container-init process.
For
Oleg Nesterov wrote:
(Not for inclusion yet, against 2.6.23-rc2, untested)
Currently, /sbin/init is protected from unhandled signals by the
"current == child_reaper(current)" check in get_signal_to_deliver().
This is not enough, we have multiple problems:
- this doesn't work for multi-t
Oleg,
I am still reviewing this patch and will try to plug in the multiple
pid ns code and play with it some more in the next couple of days.
But am curious why we need the in_interrupt() check and that too only
for the container-init process.
Also, maybe a dumb que, are the checks for SIG_IGN a
6 matches
Mail list logo
