From owner-freebsd-current Thu Sep 12 22:45:40 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E5BAA37B400; Thu, 12 Sep 2002 22:45:38 -0700 (PDT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 75F8443E72; Thu, 12 Sep 2002 22:45:38 -0700 (PDT) (envelope-from dl-freebsd@catspoiler.org) Received: from mousie.catspoiler.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.5/8.12.5) with ESMTP id g8D5jSwr002343; Thu, 12 Sep 2002 22:45:33 -0700 (PDT) (envelope-from dl-freebsd@catspoiler.org) Message-Id: <200209130545.g8D5jSwr002343@gw.catspoiler.org> Date: Thu, 12 Sep 2002 22:45:28 -0700 (PDT) From: Don Lewis Subject: Re: nfs_inactive() bug? -> panic: lockmgr: locking against myself To: iedowse@maths.tcd.ie Cc: tlambert2@mindspring.com, current@FreeBSD.ORG, jeff@FreeBSD.ORG In-Reply-To: <200209130245.aa42965@salmon.maths.tcd.ie> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 13 Sep, Ian Dowse wrote: > For example, if you hold the reference count at 1 while calling the > cleanup function, it allows that function to safely add and drop > references, but if that cleanup function has a bug that drops one > too many references then you end up recursing instead of detecting > it as a negative reference count. I've found in some other code > that it works reasonably well to leave the reference count at zero, > but set a flag to stop further 1->0 transitions from retriggering > the cleanup. Obviously other approaches will work too. The cleanup function shouldn't be mucking with the reference count, which means that the present implementation of nfs_inactive() is broken, but I think there is already general agreement on that point. The only possible exception would be to increase the reference count to pass a reference to another thread, but that would be a silly thing for a cleanup function to do, since it would no longer be cleaning up. We could add a flag that would cause an immediate panic if the cleanup function fiddled with the reference count as an aid to tracking down broken code ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message