From owner-cvs-all Thu Jan 2 9:42:36 2003 Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5945137B405 for ; Thu, 2 Jan 2003 09:42:34 -0800 (PST) Received: from mail.speakeasy.net (mail15.speakeasy.net [216.254.0.215]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE36143ED4 for ; Thu, 2 Jan 2003 09:42:32 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: (qmail 20471 invoked from network); 2 Jan 2003 17:42:36 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail15.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 2 Jan 2003 17:42:36 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.6/8.12.6) with ESMTP id h02HgUUT060235; Thu, 2 Jan 2003 12:42:30 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Thu, 02 Jan 2003 12:42:36 -0500 (EST) From: John Baldwin To: Nate Lawson Subject: Re: cvs commit: src/sys/nfsclient nfs_vnops.c Cc: cvs-committers@freebsd.org, cvs-all@freebsd.org, Alan Cox Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 27-Dec-2002 Nate Lawson wrote: > On Sun, 22 Dec 2002, Alan Cox wrote: >> Modified files: >> sys/nfsclient nfs_vnops.c >> Log: >> Avoid holding the vnode interlock around malloc() or free() to prevent a >> lock order reversal. >> >> Reviewed by: jeff >> >> Revision Changes Path >> 1.190 +8 -2 src/sys/nfsclient/nfs_vnops.c > > Shouldn't it be ok to hold it over free() (or malloc(..., M_NOWAIT) for > that matter) once Giant is removed from kmem*? What is the recommended > way to deal with LOR or other lock issues to mark them as being > unnecessary once another subsystem is cleaned up? > > /* XXX ok once Giant removed from xxx_routine() */ > > My concern is that it will be necessary to make a pass through every piece > of code that may have had locking workarounds each time a major subsystem > (malloc, proc, signals, dev_t) steps out from Giant. This is n^2. Unless you use M_NOWAIT (highly undesirable in mose cases), you need to not hold locks across malloc() anyways as it can sleep. One should be able to hold locks across free() without problems however. I would rather require callers of the code in question to hold Giant for now rather than add in hacks that have to be cleaned up later on. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message