From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5357 invoked by alias); 22 Aug 2012 13:53:09 -0000 Received: (qmail 5238 invoked by uid 22791); 22 Aug 2012 13:53:06 -0000 X-SWARE-Spam-Status: No, hits=-6.1 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 22 Aug 2012 13:52:47 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q7MDq605022863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 22 Aug 2012 09:52:06 -0400 Received: from tranklukator.brq.redhat.com (dhcp-1-232.brq.redhat.com [10.34.1.232]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP id q7MDq3mB001438; Wed, 22 Aug 2012 09:52:03 -0400 Received: by tranklukator.brq.redhat.com (nbSMTP-1.00) for uid 500 oleg@redhat.com; Wed, 22 Aug 2012 15:48:41 +0200 (CEST) Date: Wed, 22 Aug 2012 13:53:00 -0000 From: Oleg Nesterov To: Sebastian Andrzej Siewior Cc: Peter Zijlstra , linux-kernel@vger.kernel.org, x86@kernel.org, Arnaldo Carvalho de Melo , Srikar Dronamraju , Ananth N Mavinakaynahalli , stan_shebs@mentor.com, gdb-patches@sourceware.org Subject: Re: [RFC 5/5 v2] uprobes: add global breakpoints Message-ID: <20120822134837.GA28878@redhat.com> References: <1344355952-2382-1-git-send-email-bigeasy@linutronix.de> <1344355952-2382-6-git-send-email-bigeasy@linutronix.de> <1344857686.31459.25.camel@twins> <20120821194200.GA32293@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120821194200.GA32293@linutronix.de> User-Agent: Mutt/1.5.18 (2008-05-17) Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-08/txt/msg00610.txt.bz2 On 08/21, Sebastian Andrzej Siewior wrote: > > This patch adds the ability to hold the program once this point has been > passed and the user may attach to the program via ptrace. Sorry Sebastian, I didn't even try to read the patch ;) Fortunately I am not maintainer, I can only reapeat that you do not need to convince me. > Oleg: The change in ptrace_attach() is still as it was. I tried to > address Peter concern here. > Now what options do I have here: > - not putting the task in TASK_TRACED but simply halt. This would work > without a change to ptrace_attach() but the task continues on any > signal. So a signal friendly task would continue and not notice a > thing. TASK_KILLABLE > - putting the TASK_TRACED This is simply wrong, in many ways. For example, what if the probed task is already ptraced? Or debugger attaches via PTRACE_SEIZE? How can debugger know it is stopped? uprobe_wait_traced() goes to sleep in TASK_TRACED without notification. And it does not set ->exit_code, this means do_wait() won't work. And note ptrace_stop()->recalc_sigpending_tsk(). > @@ -76,6 +79,7 @@ struct uprobe_task { > > unsigned long xol_vaddr; > unsigned long vaddr; > + int skip_handler; I am trying to guess what this skip_handler does... > --- a/kernel/events/uprobes.c > +++ b/kernel/events/uprobes.c > @@ -1513,7 +1513,16 @@ static void handle_swbp(struct pt_regs *regs) > goto cleanup_ret; > } > utask->active_uprobe = uprobe; > - handler_chain(uprobe, regs); > + if (utask->skip_handler) > + utask->skip_handler = 0; > + else > + handler_chain(uprobe, regs); > + > + if (utask->state == UTASK_TRACE_WOKEUP_TRACED) { > + send_sig(SIGTRAP, current, 0); > + utask->skip_handler = 1; > + goto cleanup_ret; > + } > if (uprobe->flags & UPROBE_SKIP_SSTEP && can_skip_sstep(uprobe, regs)) > goto cleanup_ret; > > @@ -1528,7 +1537,7 @@ cleanup_ret: > utask->active_uprobe = NULL; > utask->state = UTASK_RUNNING; > } > - if (!(uprobe->flags & UPROBE_SKIP_SSTEP)) > + if (!(uprobe->flags & UPROBE_SKIP_SSTEP) || utask->skip_handler) Am I understand correctly? If it was woken by PTRACE_ATTACH we set utask->skip_handler = 1 and re-execute the instruction (yes, SIGTRAP, but this doesn't matter). When the task hits this bp again we skip handler_chain() because it was already reported. Yes? If yes, I don't think this can work. Suppose that the task dequeues a signal before it returns to the usermode to re-execute and enters the signal handler which can hit another uprobe. And this can race with uprobe_register() afaics. Oleg.