Return-Path: Received: from mx1.redhat.com ([209.132.183.28]:45441 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753110AbcDAPsp (ORCPT ); Fri, 1 Apr 2016 11:48:45 -0400 Date: Fri, 1 Apr 2016 11:48:42 -0400 (EDT) From: Benjamin Coddington To: Trond Myklebust cc: Anna Schumaker , Jeff Layton , Linux NFS Mailing List Subject: Re: [PATCH 0/3] Include OFD lock owners when looking up state In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-nfs-owner@vger.kernel.org List-ID: On Fri, 1 Apr 2016, Trond Myklebust wrote: > On Fri, Apr 1, 2016 at 11:34 AM, Benjamin Coddington > wrote: > > The client sends IO only under the open stateid when using OFD (and flock) > > locking instead of the appropriate lock stateid because the nfs_lock_context > > only tracks POSIX lockowners, which is the reference to the process' file > > table. > > > > This is a problem for two reasons. The first is that rfc7530, > > section-9.1.4.5 states that IO sent by an entity corresponding to the > > lock-owner which holds a byte-range lock should be sent under the lock > > stateid for that lock. Otherwise, a server enforcing mandatory byte-range > > locking might reject that operation. Secondly, not tracking OFD lock owners > > means that accounting for IO sent under those owners is broken. That > > creates a problem for some work to guarantee an unlock will be sent after > > operations scheduled under a lock complete. > > OK. Can we just kill this in the bud? No support for OFD locks in NFS: > this is nuts.... Will you explain why it is nuts? That would be helpful for me.