All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@redhat.com>
To: Bruce Fields <bfields@fieldses.org>
Cc: Al Viro <viro@ZenIV.linux.org.uk>,
	linux-fsdevel@vger.kernel.org,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [RFC] F_SETLEASE mess
Date: Mon, 8 Jul 2013 10:33:20 -0400	[thread overview]
Message-ID: <20130708103320.6f93b401@tlielax.poochiereds.net> (raw)
In-Reply-To: <20130708141701.GC29071@fieldses.org>

On Mon, 8 Jul 2013 10:17:01 -0400
Bruce Fields <bfields@fieldses.org> 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 <jlayton@redhat.com>

  reply	other threads:[~2013-07-08 14:33 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-05  9:04 [RFC] F_SETLEASE mess Al Viro
2013-07-05 10:51 ` Jeff Layton
2013-07-05 12:08   ` Jeff Layton
2013-07-05 16:25     ` Bruce Fields
2013-07-05 21:46       ` Jeff Layton
2013-07-08 14:17         ` Bruce Fields
2013-07-08 14:33           ` Jeff Layton [this message]
2013-07-08 18:10           ` Myklebust, Trond
2013-07-08 18:53             ` Bruce Fields
2013-07-08 19:21               ` Myklebust, Trond
2013-07-08 19:34                 ` Bruce Fields
2013-07-08 20:14                   ` Myklebust, Trond
2013-07-08 21:17                     ` Bruce Fields
2013-07-08 22:25                       ` Myklebust, Trond
2013-07-08 23:19                         ` Bruce Fields

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130708103320.6f93b401@tlielax.poochiereds.net \
    --to=jlayton@redhat.com \
    --cc=bfields@fieldses.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@ZenIV.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.