From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12627 invoked by alias); 14 Jun 2010 17:43:07 -0000 Received: (qmail 12617 invoked by uid 22791); 14 Jun 2010 17:43:05 -0000 X-SWARE-Spam-Status: No, hits=-5.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD 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; Mon, 14 Jun 2010 17:42:53 +0000 Received: from int-mx04.intmail.prod.int.phx2.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.17]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o5EHgo3J008275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 14 Jun 2010 13:42:50 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx04.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o5EHgnUI027435; Mon, 14 Jun 2010 13:42:49 -0400 Subject: Re: [Bug uprobes/11672] utrace_report_syscall_exit crash From: Mark Wielaard To: Roland McGrath Cc: systemtap@sources.redhat.com In-Reply-To: <20100614165856.C16DF408C3@magilla.sf.frob.com> References: <20100607130056.11672.mjw@redhat.com> <20100609143920.1986.qmail@sourceware.org> <20100614084019.7F188408C2@magilla.sf.frob.com> <1276507085.4140.27.camel@springer.wildebeest.org> <20100614165856.C16DF408C3@magilla.sf.frob.com> Content-Type: text/plain; charset="UTF-8" Date: Mon, 14 Jun 2010 21:32:00 -0000 Message-ID: <1276537368.9961.31.camel@hermans.wildebeest.org> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2010-q2/txt/msg00554.txt.bz2 On Mon, 2010-06-14 at 09:58 -0700, Roland McGrath wrote: > > This is called from the task finder cleanup code and the utrace probe > > exit code before the module tries to unload. > > From a quick glance I'm still not really clear on the important question: > what thread is current when calling into this code? I think it depends on which method of exiting/unloading is being used. As far as I understand the code this is called from the proc transport on response to an exit packet being writen to our .cmd file. Otherwise it is done through DECLARE_DELAYED_WORK, but I am not completely sure how that works. Maybe someone who hacked on the transport layer can explain the precise interactions. > > Busy-waiting is bad, so if there is an alternative that would be nice. > > All we need is that if after a utrace_control UTRACE_DETACH we get an > > -EINPROGRESS that we can wait till we are sure any pending handlers have > > finished and that the detach fully succeeded. > > As I said, utrace_barrier is that except that it's a busy-wait if > signal_pending(). The alternative requires changing your model such that > any waiting is via your own synchronization with your ops->release > function. OK, thanks. The current solution seems to make things more stable (I am unable to trigger any crashes anymore). Lets not rewrite the whole synchronization just for this small possibility of a busy wait. Unless someone else wants to of course. Cheers, Mark