From owner-cvs-all Fri Dec 27 11:45:51 2002 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 EDB2537B401; Fri, 27 Dec 2002 11:45:49 -0800 (PST) Received: from cleitus.hosting.swbell.net (cleitus.hosting.swbell.net [216.100.99.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id DFC5C43E4A; Fri, 27 Dec 2002 11:45:48 -0800 (PST) (envelope-from alc@imimic.com) Received: from imimic.com (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) by cleitus.hosting.swbell.net id OAA20068; Fri, 27 Dec 2002 14:45:37 -0500 (EST) [ConcentricHost SMTP Relay 1.14] Message-ID: <3E0CADD9.7D5A71F7@imimic.com> Date: Fri, 27 Dec 2002 13:45:29 -0600 From: "Alan L. Cox" Organization: iMimic Networking, Inc. X-Mailer: Mozilla 4.8 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: Nate Lawson Cc: Alan Cox , cvs-all@freebsd.org, cvs-committers@freebsd.org Subject: Re: cvs commit: src/sys/nfsclient nfs_vnops.c References: Content-Type: text/plain; charset=x-user-defined Content-Transfer-Encoding: 7bit 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 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*? In general, it is ok. The vnode interlock is, however, a special case because vnodes are closely tied to vm_objects. For example, the removal of a page from a vm_object can trigger changes to the related vnode. (See vm_page_free_toq().) In other words, this is a LOR with or without Giant. > ... 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() */ That would certainly be helpful. Another possibility is to use lock assertions. > 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. In general, don't worry. There will, however, be special cases, like vnodes and vm_objects, where the subsystems interact in more complex ways than subsystem A calls subsystem B. Those cases will likely require work in both subsystems as our locking schemes evolve. Regards, Alan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message