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 <a...@linux-foundation.org> > > Cc: Oleg Nesterov <o...@redhat.com> > > Signed-off-by: Jamie Iles <jamie.i...@oracle.com> > > --- > > 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 > > >
