From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15897 invoked by alias); 30 Aug 2012 20:42:50 -0000 Received: (qmail 15886 invoked by uid 22791); 30 Aug 2012 20:42:49 -0000 X-SWARE-Spam-Status: No, hits=-3.4 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_HOSTKARMA_NO,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from www.linutronix.de (HELO Galois.linutronix.de) (62.245.132.108) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 30 Aug 2012 20:42:36 +0000 Received: from localhost ([127.0.0.1] helo=[172.123.10.21]) by Galois.linutronix.de with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1T7BZ6-0000mz-Ha; Thu, 30 Aug 2012 22:42:12 +0200 Message-ID: <503FD021.6060804@linutronix.de> Date: Thu, 30 Aug 2012 20:42:00 -0000 From: Sebastian Andrzej Siewior User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.6esrpre) Gecko/20120817 Icedove/10.0.6 MIME-Version: 1.0 To: Oleg Nesterov 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 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> <20120822134837.GA28878@redhat.com> <503BC2F1.5060003@linutronix.de> <20120829154952.GA29101@redhat.com> In-Reply-To: <20120829154952.GA29101@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 X-IsSubscribed: yes 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/msg00879.txt.bz2 On 08/29/2012 05:49 PM, Oleg Nesterov wrote: >> That would help but would require a change in ptrace_attach() or >> something in gdb/strace/… > > Well, I still think you should not touch ptrace_attach() at all. Okay. >> One thing I just noticed: If I don't register a handler for SIGUSR1 and >> send one to the application while it is in TASK_KILLABLE then the >> signal gets delivered. > > Not really delivered... OK, it can be delivered (dequeued) before > the task sees SIGKILL, but this can be changed. > > In short: in this case the task is correctly SIGKILL'ed. See sig_fatal() > in complete_signal(). > >> If I register a signal handler for it than it >> gets blocked and delivered once I resume the task. > > Sure, if you have a handler, the signal is not fatal. > >> Shouldn't it get blocked even if I don't register a handler for it? > > No. Now, that I read again it looks like a brain fart on my side. >> ach, those signals make everything complicated. I though signals are >> blocked until the single step is done > > Yes, see uprobe_deny_signal(). > >> but my test just showed my >> something different. > > I guess you missed the UTASK_SSTEP_TRAPPED logic. > > But this doesn't matter. Surely we must not "block" signals _after_ > the single step is done, and this is the problem. > >> Okay, what now? > > IMHO: don't do this ;) > >> Blocking signals isn't probably a good idea. > > This is bad and wrong idea, I think. > > And, once again. Whatever you do, you can race with uprobe_register(). > I mean, you must never expect that the task will hit the same uprobe > again, even if you are going to re-execute the same insn. After witting why I think you are wrong I understood what you meant :) So let me try to get this right… > > Oleg. Sebastian