From owner-freebsd-fs@FreeBSD.ORG Mon Apr 13 18:37:36 2009 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 C8CF5106566C; Mon, 13 Apr 2009 18:37:36 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from acadia.cs.uoguelph.ca (acadia.cs.uoguelph.ca [131.104.94.221]) by mx1.freebsd.org (Postfix) with ESMTP id 6DFD48FC08; Mon, 13 Apr 2009 18:37:36 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by acadia.cs.uoguelph.ca (8.13.1/8.13.1) with ESMTP id n3DIbZxQ031333; Mon, 13 Apr 2009 14:37:35 -0400 Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id n3DIi1n06133; Mon, 13 Apr 2009 14:44:02 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Mon, 13 Apr 2009 14:44:01 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: John Baldwin In-Reply-To: <200904131146.21640.jhb@freebsd.org> Message-ID: References: <200904131146.21640.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.63 on 131.104.94.221 Cc: freebsd-fs@freebsd.org Subject: Re: integrating nfsv4 locking with nlm and local locking 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: Mon, 13 Apr 2009 18:37:37 -0000 On Mon, 13 Apr 2009, John Baldwin wrote: > > You have to hold the vnode lock to set a VV flag always. Even if you do an > atomic operation to set your flag, another thread might be setting a flag at > the same time using non-atomic ops and could clobber your change (if it does > a read-modify-write and reads a value that pre-dates your atomic_set_int() > but its write posts after your write). > Righto, thanks. (I should have realized that.) I guess I'll have to use a VI_xxx flag or add a field to the vnode to make the scheme work. I am just trying to come up with a stopgap solution until something more comprehensive can be done w.r.t. handling delegations. VI_xxx are currently used for handling the vnode and it doesn't seem appropriate to add one of these to indicate "don't issue delegations". How do others feel w.r.t. adding a VI_xxx flag vs adding v_disabledelegate to the structure? There is always the fallback position of shipping an nfsv4 server with delegations disabled, until handling them when local VOPs are done, gets resolved. rick