From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932327AbcHSBHM (ORCPT ); Thu, 18 Aug 2016 21:07:12 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38316 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932290AbcHSBHH (ORCPT ); Thu, 18 Aug 2016 21:07:07 -0400 Date: Thu, 18 Aug 2016 17:38:06 +0200 From: Oleg Nesterov To: Keno Fischer Cc: roland@hack.frob.com, linux-kernel@vger.kernel.org, Tejun Heo Subject: Re: ptrace group stop signal number not reset before PTRACE_INTERRUPT is delivered? Message-ID: <20160818153806.GA25492@redhat.com> References: <20160818143750.GA24070@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160818143750.GA24070@redhat.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Thu, 18 Aug 2016 15:38:26 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 08/18, Oleg Nesterov wrote: > > On 08/17, Keno Fischer wrote: > > > > In this test case, the last > > group-stop (after PTRACE_INTERRUPT) is delivered with a > > WSTOPSIG(status) of SIGTTIN, which was the signr of the previous group > > stop. From reading the man-page, I would have expected SIGTRAP. > > Me too ;) Yes, but on the second though... > > Now, I > > understand that if there is another stop pending, PTRACE_INTERRUPT > > will simply piggy-backs off that one, but I don't believe that is > > happening in this case. > > Yes, thanks. This is wrong. We need to remove SIGTTIN from jobctl. > The problem, I am not sure when... I'll try to think. Probably not. Let me try to clarify. It reports SIGTTIN because your test-case doesn't send SIGCONT to the tracee before PTRACE_INTERRUPT. Because the child is stopped-but-running. IOW, after the tracer acks SIGSTOP err = ptrace(PTRACE_CONT, child, NULL, (void*)SIGSTOP); the child actually starts the group-stop and becomes "STOPPED", so that if you do ptrace_detach() after that it will stop again in TASK_STOPPED state even if it is no longer traced. Then SIGTTIN changes the signal number in "jobctl & JOBCTL_STOP_SIGMASK", the tracee is still "STOPPED" but now it looks as if it was stopped by SIGTTIN, not by SIGSTOP. Hmm, not sure this is really good, but we can't use signal->group_exit_code. Finally, after PTRACE_INTERRUPT the tracee "returns" to the "STOPPED" state and reports SIGTTIN, and I agree this looks confusing... But I'm not sure we should/can change this, this behaviour probably makes sense too. Damn. I'll try to think more, but I simply can't decide what do we actually want in this case. Oleg.