Date: Fri, 27 Apr 2001 18:03:08 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: bright@wintelcom.net (Alfred Perlstein) Cc: smp@FreeBSD.ORG, dillon@FreeBSD.ORG, jhb@FreeBSD.ORG Subject: Re: that vm diff now makes it into single user mode. Message-ID: <200104271803.LAA02107@usr07.primenet.com> In-Reply-To: <20010427042619.W18676@fw.wintelcom.net> from "Alfred Perlstein" at Apr 27, 2001 04:26:19 AM
next in thread | previous in thread | raw e-mail | index | archive | help
> Getting into UFS is starting to get somewhat hairy as there seems > like there's going to be a lock of lock/unlock or places where the > lock is held for a long period. FWIW: The correact approach to this is to lock the vnode, and treat everything lower than that as "opaque". If you can lock the vnode, you can make any call you want on it. Part of the problem here os some of the earlier "clean up" work that damaged the VFS interface. Really, the locks need to be asserted in the VOP_* macro, prior to calldown, and the locks need to be reentrant for the time being, for the same VFS. The easiest way to do this is to realize that there is no tail call optimization in the VFS code, _anywhere_, and just say "VOP_* calls from outside the VFS must lock the vnode, and VOP_* calls from withing the VFS must not, since the vnode will already be locked, UNLESS it is an internally acquired vnode that didn't come down from outside the VFS code". A gross approximation of this would be to put locks in all the VOP_ calls, and then pass a "do_lock" flag to all of them which is always "1" for code above the VFS layer (e.g. /sys/kerne/vfs_*.c), and _only occasionally_ "1" for calls from within the VFS layer (mostly "rename", "lookup", "delete", and other directory entry manipulation code in UFS, proper). You will need to "punt" on multithreading each VFS itself, until some later date (the only thing you will lose when doing this is the ability go into the same directory simultaneously on more than one processor). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200104271803.LAA02107>