From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28747 invoked by alias); 6 Jan 2012 17:01:11 -0000 Received: (qmail 28735 invoked by uid 22791); 6 Jan 2012 17:01:10 -0000 X-SWARE-Spam-Status: No, hits=-6.4 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; Fri, 06 Jan 2012 17:00:51 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q06H0nWw027778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 6 Jan 2012 12:00:49 -0500 Received: from t510.usersys.redhat.com (vpn-10-240.rdu.redhat.com [10.11.10.240]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q06H0m78005469 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 6 Jan 2012 12:00:48 -0500 Message-ID: <4F0728BF.6010200@redhat.com> Date: Fri, 06 Jan 2012 17:01:00 -0000 From: David Smith User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: Srikar Dronamraju CC: Frank Ch Eigler , systemtap@sourceware.org Subject: Re: [Bug uprobes/13539] occasional oops, kernel SEGV, RHEL5, :uprobes:uprobe_free_process+0xba/0x131 References: <20120106122516.GA17178@linux.vnet.ibm.com> In-Reply-To: <20120106122516.GA17178@linux.vnet.ibm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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: 2012-q1/txt/msg00009.txt.bz2 On 01/06/2012 06:25 AM, Srikar Dronamraju wrote: > > While I still cannot see a reason how uprobe_{free,put}_process can > race uprobe_report_{exit,exec}, I certainly think somebit of cleanup > can be done. However I am dont think we need to do a utask or uproc lookup > from the table. Especially in case of callbacks. > > Mostly similar to what Jim proposed. > I havent tested this patch myself and I couldnt reproduce the problem. With your patch, I got the same stapio hang as I mentioned in comment #5 on the bug, but happened on the 3rd run of the unprivileged_myproc.exp test case (it has happened on every run with the pr13539 branch code for me). So your code is a slight improvement. That comment also describes my environment in duplicating the bug which might help you. -- David Smith dsmith@redhat.com Red Hat http://www.redhat.com 256.217.0141 (direct) 256.837.0057 (fax)