Date: Sun, 31 Aug 2008 14:58:34 -0400 (EDT) From: Rick Macklem <rmacklem@uoguelph.ca> To: Kostik Belousov <kostikbel@gmail.com> Cc: freebsd-fs@freebsd.org Subject: Re: Is curthread always valid in a VOP call? Message-ID: <Pine.GSO.4.63.0808311446230.685@muncher.cs.uoguelph.ca> In-Reply-To: <20080831061218.GJ2038@deviant.kiev.zoral.com.ua> References: <Pine.GSO.4.63.0808301922050.21141@muncher.cs.uoguelph.ca> <20080831061218.GJ2038@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 31 Aug 2008, Kostik Belousov wrote: > On Sat, Aug 30, 2008 at 07:23:07PM -0400, Rick Macklem wrote: >> Since VOP_GETATTR() and VOP_SETATTR() lost the thread argument in >> -current, I did the obvious and used "curthread" instead. Is this >> safe to do? > > Yes. Does the change forced you to use curthread often ? > Ok, thanks. How often? 7 (or 2 if I "struct thread *td = curthread; at the beginning of nfs_getattr() and nfs_setattr() like the vanilla nfsclient has done). Basically, any NFS VOP is going to end up doing an RPC sooner or later (if it's lucky, it hits a cache, but...) and the RPC currently likes to have a thread/proc pointer so it can check for termination signals for interruptible mounts. Personally, I'm not fond of interruptible mounts (they're hard to get right and almost impossible to do correctly for NFS4) and prefer hard mounts + forced dismounts when a server is dead. But, I'm not sure others would be ready to get rid of them. So, until interruptible mounts go away, I can't see avoiding a thread pointer for the RPC and that means either pass it down the calling chain or use curthread at some point. (Doesn't matter to me which it is, so long as it works.) rick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.63.0808311446230.685>