Date: Fri, 27 Dec 2002 10:45:15 -0800 (PST) From: Nate Lawson <nate@root.org> To: Alan Cox <alc@FreeBSD.org> Cc: cvs-all@freebsd.org, cvs-committers@freebsd.org Subject: Re: cvs commit: src/sys/nfsclient nfs_vnops.c Message-ID: <Pine.BSF.4.21.0212271039390.78794-100000@root.org> In-Reply-To: <20021223062045.CC59237B48B@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -Nate 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?Pine.BSF.4.21.0212271039390.78794-100000>