From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff Layton Subject: Re: [RFC] F_SETLEASE mess Date: Mon, 8 Jul 2013 10:33:20 -0400 Message-ID: <20130708103320.6f93b401@tlielax.poochiereds.net> References: <20130705090449.GQ4165@ZenIV.linux.org.uk> <1373021495.2216.25.camel@tlielax.poochiereds.net> <1373026124.4269.2.camel@tlielax.poochiereds.net> <20130705162518.GD29747@fieldses.org> <1373060779.2261.11.camel@tlielax.poochiereds.net> <20130708141701.GC29071@fieldses.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Al Viro , linux-fsdevel@vger.kernel.org, Linus Torvalds To: Bruce Fields Return-path: Received: from mx1.redhat.com ([209.132.183.28]:23898 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751926Ab3GHOd0 (ORCPT ); Mon, 8 Jul 2013 10:33:26 -0400 In-Reply-To: <20130708141701.GC29071@fieldses.org> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Mon, 8 Jul 2013 10:17:01 -0400 Bruce Fields wrote: > On Fri, Jul 05, 2013 at 05:46:19PM -0400, Jeff Layton wrote: > > I think the bigger issue though is that looking at refcounts in order to > > determine when we have a conflicting open is just plain wrong. There are > > all sorts of reasons one might see a raised refcount that don't involve > > conflicting opens (Al's stat() example for instance). It seems like we > > ought to shoot for a solution that doesn't rely (solely) on inode and > > dentry refcounts. > > Note that NFSv4 write delegations will need to affect stat as well. > (Once you let a client perform writes locally, that client becomes the > authority on the attributes, so we have to call back to it on stat.) > > --b. Good point... I'm a little leery of changing how that check is done anyway. While it seems intuitive to (re)implement the i_readcount in a similar way to the i_writecount, I'd be concerned about callers relying on the existing behavior. So, I'm inclined to try and fix the race that Al has identified without changing the logic too much. -- Jeff Layton