From owner-freebsd-fs@FreeBSD.ORG Sun Aug 31 18:46:16 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A08091065675 for ; Sun, 31 Aug 2008 18:46:16 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from mailhub.cs.uoguelph.ca (mailhub.cs.uoguelph.ca [131.104.94.205]) by mx1.freebsd.org (Postfix) with ESMTP id 468068FC1E for ; Sun, 31 Aug 2008 18:46:16 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by mailhub.cs.uoguelph.ca (8.13.1/8.13.1) with ESMTP id m7VIkFu9030972; Sun, 31 Aug 2008 14:46:15 -0400 Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id m7VIwY402680; Sun, 31 Aug 2008 14:58:34 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Sun, 31 Aug 2008 14:58:34 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Kostik Belousov In-Reply-To: <20080831061218.GJ2038@deviant.kiev.zoral.com.ua> Message-ID: References: <20080831061218.GJ2038@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.63 on 131.104.94.205 Cc: freebsd-fs@freebsd.org Subject: Re: Is curthread always valid in a VOP call? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Aug 2008 18:46:16 -0000 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