Date: Thu, 02 Jan 2003 12:42:36 -0500 (EST) From: John Baldwin <jhb@FreeBSD.org> To: Nate Lawson <nate@root.org> Cc: cvs-committers@freebsd.org, cvs-all@freebsd.org, Alan Cox <alc@FreeBSD.org> Subject: Re: cvs commit: src/sys/nfsclient nfs_vnops.c Message-ID: <XFMail.20030102124236.jhb@FreeBSD.org> In-Reply-To: <Pine.BSF.4.21.0212271039390.78794-100000@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <jhb@FreeBSD.org> <>< 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.20030102124236.jhb>