Date: Fri, 27 Dec 2002 13:45:29 -0600 From: "Alan L. Cox" <alc@imimic.com> To: Nate Lawson <nate@root.org> Cc: Alan Cox <alc@FreeBSD.org>, cvs-all@freebsd.org, cvs-committers@freebsd.org Subject: Re: cvs commit: src/sys/nfsclient nfs_vnops.c Message-ID: <3E0CADD9.7D5A71F7@imimic.com> References: <Pine.BSF.4.21.0212271039390.78794-100000@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E0CADD9.7D5A71F7>