From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757705AbcCUTgh (ORCPT ); Mon, 21 Mar 2016 15:36:37 -0400 Received: from mx1.redhat.com ([209.132.183.28]:51626 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757535AbcCUTgf (ORCPT ); Mon, 21 Mar 2016 15:36:35 -0400 Date: Mon, 21 Mar 2016 20:35:25 +0100 From: Oleg Nesterov To: Patrick Donnelly Cc: Tejun Heo , linux-kernel@vger.kernel.org Subject: Re: Question regarding ptrace work for LInux v3.1 Message-ID: <20160321193524.GA9494@redhat.com> References: <20160321174755.GA4747@redhat.com> <20160321190758.GA8230@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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.38]); Mon, 21 Mar 2016 19:36:35 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/21, Patrick Donnelly wrote: > > On Mon, Mar 21, 2016 at 3:07 PM, Oleg Nesterov wrote: > > > > Yes, exactly, you need to see the initial SIGSTOP or another event which > > can be reported before it. > > Assuming a SIGSTOP is being silenced, is there anything we can do to > forcibly start tracing syscalls? (For kernels without PTRACE_SEIZE) No. Only PTRACE_SYSCALL can set TIF_SYSCALL_TRACE. > > case SIGSTOP: > > /* Black magic to get threads working on old Linux kernels... */ > > > > if(p->nsyscalls == 0) { /* stop before we begin running the process */ > > debug(D_DEBUG, "suppressing bootstrap SIGSTOP for %d",pid); > > signum = 0; /* suppress delivery */ > > kill(p->pid,SIGCONT); > > } > > break; > > > > doesn't look right. Note that kill(pid,SIGCONT) affects the whole thread- > > group. So if this kill() races with another thread doing clone() you can > > hit the problem you described. > > You're right, that should be tkill! I will give that a try and report > back if that solved the issue for our collaborators... Ah, sorry, I should have mentioned this... No, tkill() won't help. See prepare_signal(), SIGCONT always removes the SIG_KERNEL_STOP_MASK signals from all threads, not matter if it was sent by tkill() or kill(). Perhaps you should just remove this kill(SIGCONT) ? tracer_continue(signr => 0) should equally suppress the delivery. To clarify this won't be right too, but without PTRACE_SEIZE you simply can't write the code which handles the stop/cont/etc events correctly anyway... > >> > But unless you use PTRACE_SEIZE the same can happen on v3.1 so it seems > >> > there is something else. > >> > >> Okay, it might be that PTRACE_SEIZE fixes it. > > > > Yes, but iiuc you do not see this problem on v3.1 even with PTRACE_ATTACH? > > I have not tested on >v3.1 with PTRACE_ATTACH. OK, thanks. So perhaps this is not v3.0-specific. Oleg.