From owner-freebsd-fs@FreeBSD.ORG Mon Apr 13 17:55:37 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 16E80106566C for ; Mon, 13 Apr 2009 17:55:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 454AC8FC1A for ; Mon, 13 Apr 2009 17:55:36 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 76A7946B5C; Mon, 13 Apr 2009 13:55:34 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id A903F8A04D; Mon, 13 Apr 2009 13:54:45 -0400 (EDT) From: John Baldwin To: freebsd-fs@freebsd.org Date: Mon, 13 Apr 2009 11:46:21 -0400 User-Agent: KMail/1.9.7 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904131146.21640.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 13 Apr 2009 13:54:45 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=0.1 required=4.2 tests=RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: 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 17:55:37 -0000 On Thursday 09 April 2009 3:04:37 pm Rick Macklem wrote: > My nfsv4 server currently does VOP_ADVLOCK() with the non-blocking F_SETLK > type and I had thought that was sufficient, but I now realize (thanks to > a recent post by Zachary Loafman) that this breaks when a delegation for > the file is issued to a client. (When a delegation for a file is issued > to a client, it can do byte range locking locally, and the server doesn't > know about these to do VOP_ADVLOCK() on the server machine.) > > I believe that Zachary would like to discuss a more general solution, > including how to handle Open/Share locks, but in the meantime I'd like to > solve this specific case in as simple a way as possible. > > Basically, I need a way to make sure delegations for a file don't exist > when local byte range locking or locking via the NLM is being done on > the file. > > The simplest thing I can think of is the following: > When VOP_ADVLOCK() is called for a file (outside of the nfsv4 server), > do two things: > 1 - Make sure any outstanding delegations are recalled. > I already have a function that does this, so it is a matter > of figuring out where to put the call(s). > 2 - Set a flag on the vnode, so that my nfsv4 server knows not to > issue another delegation for that file. > (I could test for locks via VOP_ADVLOCK() before issuing a > delegation, but that has two problems.) > 1 - Since the vnode is unlocked for VOP_ADVLOCK(), there could > be a race where the nfsv4 server issues a delegation > between the time outstanding delegations are recalled at > #1 above and the VOP_ADVLOCK() sets the lock that I would > see during the test. > 2 - It would have to keep checking for a lock and might issue > a delegation at a point where no lock is held, but one > will be acquired soon, forcing the delegation recall. > (It's much easier to not issue a delegation than recall > one.) > Once this flag is set, I think it would be ok if the flag > remains set until the vnode is recycled, since it seems > fairly likely that, once byte range locking is done on a > file, more will happen. > (If people were agreeable to the vnode flag, it looks like > a VV_xxx flag would make more sense than a VI_xxx one. I > think an atomic_set_int() would be sufficient to set it, > even though the vnode lock isn't held?) 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). -- John Baldwin