Hi Oleg,
On Fri, May 05, 2017 at 06:26:07PM +0200, Oleg Nesterov wrote:
> Hi Jamie,
>
> I am sorry for being slow... yes, probably we should start with this
> simple change, and perhaps we do not really need anything else. But
> let me think about this till Monday, perhaps we can remove this "clear
> SIGNAL_UNKILLABLE" logic in force_sig_info() altogether.
I was wondering if you had given this any more thought?
Thanks,
Jamie
> On 05/04, Jamie Iles wrote:
> >
> > When forcing a signal, SIGNAL_UNKILLABLE is removed to prevent recursive
> > faults, but this is undesirable when tracing. For example, debugging an
> > init process (whether global or namespace), hitting a breakpoint and
> > SIGTRAP will force SIGTRAP and then remove SIGNAL_UNKILLABLE.
> > Everything continues fine, but then once debugging has finished, the
> > init process is left killable which is unlikely what the user expects,
> > resulting in either an accidentally killed init or an init that stops
> > reaping zombies.
> >
> > Cc: Andrew Morton <[email protected]>
> > Cc: Oleg Nesterov <[email protected]>
> > Signed-off-by: Jamie Iles <[email protected]>
> > ---
> > kernel/signal.c | 6 +++++-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/kernel/signal.c b/kernel/signal.c
> > index 7e59ebc2c25e..5516a0cda668 100644
> > --- a/kernel/signal.c
> > +++ b/kernel/signal.c
> > @@ -1185,7 +1185,11 @@ force_sig_info(int sig, struct siginfo *info, struct task_struct *t)
> > recalc_sigpending_and_wake(t);
> > }
> > }
> > - if (action->sa.sa_handler == SIG_DFL)
> > + /*
> > + * Don't clear SIGNAL_UNKILLABLE for traced tasks, users won't expect
> > + * debugging to leave init killable.
> > + */
> > + if (action->sa.sa_handler == SIG_DFL && !t->ptrace)
> > t->signal->flags &= ~SIGNAL_UNKILLABLE;
> > ret = specific_send_sig_info(sig, info, t);
> > spin_unlock_irqrestore(&t->sighand->siglock, flags);
> > --
> > 2.12.0.rc0
> >
>