Date: Fri, 6 Dec 2002 20:11:14 -0500 (EST) From: Robert Watson <rwatson@freebsd.org> To: "David E. Cross" <crossd@cs.rpi.edu> Cc: fs@freebsd.org Subject: Re: AFS nastiest hack ever question Message-ID: <Pine.NEB.3.96L.1021206200945.5166Q-100000@fledge.watson.org> In-Reply-To: <200211291011.gATABpU07028@monica.cs.rpi.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 29 Nov 2002, David E. Cross wrote: > Just when I thought I was done ;) > > Ok.. Quick summary. "afs_symlink" will panic the kernel. The problem > is that the symlink syscall expects VOP_SYSCALL to fill in the "vpp" > with the vnode of the newly created symlink. AFS doesn't do this, ever, > it, internally creates its private vnode, and then calls its own "vput" > on it, immediately claiming it back to the system (which is good in some > ways since afs vnodes don't play nice with system vnodes). To "fix" > this I would need to significantly modify AFS's code. Or... what I have > done is to : If OpenAFS has its own vnode handling for the reclaim of the vnode by the OS when its reference count drops to 0, it should be able to handle the consumer of VOP_SYMLINK() returning the reference just fine. This would be no different than the consumer of namei() returning the vnode when it isn't needed. I'd probably just #if 0 the vput in the OpenAFS code. As you observe, our VFS assumes that you do return the vnode so that you can perform race-free operations on the symlink, for better or for worse... Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1021206200945.5166Q-100000>