Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1432118AbdDYRjn (ORCPT ); Tue, 25 Apr 2017 13:39:43 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:32196 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1430020AbdDYRjf (ORCPT ); Tue, 25 Apr 2017 13:39:35 -0400 Date: Tue, 25 Apr 2017 18:39:28 +0100 From: Jamie Iles To: Oleg Nesterov , linux-kernel@vger.kernel.org Subject: SIGNAL_UNKILLABLE and init again Message-ID: <20170425173928.gaubfmxxbbvglnio@cedar> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.6.2-neo (2016-08-21) X-Source-IP: aserv0021.oracle.com [141.146.126.233] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1049 Lines: 32 Hi Oleg, I'm back looking at SIGNAL_UNKILLABLE and debugging child reapers again, and the current issue is when running code in the target process, SIGTRAP firing and that causing SIGNAL_UNKILLABLE protection to be removed in force_sig_info(): if (action->sa.sa_handler == SIG_DFL) t->signal->flags &= ~SIGNAL_UNKILLABLE; Would relaxing that if the task is being traced with something like diff --git i/kernel/signal.c w/kernel/signal.c index 7e59ebc2c25e..f701f1889895 100644 --- i/kernel/signal.c +++ w/kernel/signal.c @@ -1185,7 +1185,7 @@ force_sig_info(int sig, struct siginfo *info, struct task_struct *t) recalc_sigpending_and_wake(t); } } - if (action->sa.sa_handler == SIG_DFL) + 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); make any sense? It does address the issue that I'm seeing, but are there any downsides to doing so? Thanks, Jamie