From owner-freebsd-stable@FreeBSD.ORG Thu Feb 1 16:02:12 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4615F16A400 for ; Thu, 1 Feb 2007 16:02:12 +0000 (UTC) (envelope-from ghelmer@palisadesys.com) Received: from magellan.palisadesys.com (magellan.palisadesys.com [192.188.162.211]) by mx1.freebsd.org (Postfix) with ESMTP id 0FFF413C491 for ; Thu, 1 Feb 2007 16:02:11 +0000 (UTC) (envelope-from ghelmer@palisadesys.com) Received: from [172.16.2.242] (cetus.palisadesys.com [192.188.162.7]) (authenticated bits=0) by magellan.palisadesys.com (8.13.8/8.13.8) with ESMTP id l11G21KF036462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 1 Feb 2007 10:02:02 -0600 (CST) (envelope-from ghelmer@palisadesys.com) Message-ID: <45C20F00.4010900@palisadesys.com> Date: Thu, 01 Feb 2007 10:02:08 -0600 From: Guy Helmer User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <45C0C749.1040300@palisadesys.com> In-Reply-To: <45C0C749.1040300@palisadesys.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (magellan.palisadesys.com [192.188.162.211]); Thu, 01 Feb 2007 10:02:02 -0600 (CST) X-Palisade-MailScanner-Information: Please contact the ISP for more information X-Palisade-MailScanner: Found to be clean X-Palisade-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-4.399, required 6, autolearn=not spam, ALL_TRUSTED -1.80, BAYES_00 -2.60) X-Palisade-MailScanner-From: ghelmer@palisadesys.com Subject: Re: 6.2 amd64 panic: lockmgr: thread 0xffffff009f9fd000, not exclusive lock holder 0xffffff003961c000 unlocking X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2007 16:02:12 -0000 Guy Helmer wrote: > Does this make sense to anyone (it doesn't to me - procfs_doprofile > simply locks, calls vn_fullpath, and unlocks)? I was trying to track > down a hang by running a system under stress, and instead got this > panic as a result of a process running a perl script that looks > through /proc/; it occurred on a very busy system with lots of process > churn. Does this change to src/sys/fs/procfs.c make sense? From my reading, it is possible for vn_lock(9) to fail... Index: procfs.c =================================================================== RCS file: /home/ncvs/src/sys/fs/procfs/procfs.c,v retrieving revision 1.12.2.1 diff -u -r1.12.2.1 procfs.c --- procfs.c 14 Jun 2006 21:20:39 -0000 1.12.2.1 +++ procfs.c 1 Feb 2007 15:19:30 -0000 @@ -69,8 +69,11 @@ { char *fullpath = "unknown"; char *freepath = NULL; + int err; - vn_lock(p->p_textvp, LK_EXCLUSIVE | LK_RETRY, td); + if ((err = vn_lock(p->p_textvp, LK_EXCLUSIVE | LK_RETRY, td)) != 0) { + return (err); + } vn_fullpath(td, p->p_textvp, &fullpath, &freepath); VOP_UNLOCK(p->p_textvp, 0, td); sbuf_printf(sb, "%s", fullpath);