From: Mimi Zohar <zohar@linux.vnet.ibm.com>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: linux-nfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
samba-technical@lists.samba.org,
Christoph Hellwig <hch@infradead.org>,
Eric Paris <eparis@redhat.com>
Subject: Re: [PATCH 1/2] locks: introduce i_blockleases to close lease races
Date: Sun, 12 Jun 2011 15:10:04 -0400 [thread overview]
Message-ID: <1307905804.3564.28.camel@localhost.localdomain> (raw)
In-Reply-To: <20110612040826.GD9246@fieldses.org>
On Sun, 2011-06-12 at 00:08 -0400, J. Bruce Fields wrote:
> On Fri, Jun 10, 2011 at 05:34:46PM -0400, J. Bruce Fields wrote:
> > On Fri, Jun 10, 2011 at 04:24:00PM -0400, Mimi Zohar wrote:
> > > On Thu, 2011-06-09 at 20:10 -0400, J. Bruce Fields wrote:
> > > > From: J. Bruce Fields <bfields@redhat.com>
> > > >
> > > > Since break_lease is called before i_writecount is incremented, there's
> > > > a window between the two where a setlease call would have no way to know
> > > > that an open is about to happen.
> > >
> > > So unless the break_lease() call is moved from may_open() to after
> > > nameidata_to_filp(), I don't see any other options.
> >
> > Actually, offhand I can't see why that wouldn't be OK.
> >
> > Though I think we still end up needing something like i_blockleases to
> > handle unlink, link, rename, chown, and chmod.
>
> Well, I guess there's a bizarre alternative that wouldn't require a new
> inode field:
In lieu of adding a new inode field, another possible option, a bit
kludgy, would be extending i_flock with an additional fl_flag
FL_BLOCKLEASE.
#define IS_BLOCKLEASE(fl) (fl->fl_flags & FL_BLOCKLEASE)
Mimi
> What we care about is conflicts between read leases and operations that
> modify the metadata of the inode or the set of names pointing to it.
>
> As far as I can tell those operations all take the i_mutex either on the
> inode itself or on the parents of one of its aliases.
>
> So, you could prevent break_lease/setlease races by calling setlease
> under *all* of those i_mutexes:
>
> - take i_mutex on the inode
> - take i_lock to prevent the set of aliases from changing
> - take i_mutex for parent of each alias
> - set the lease
> - drop the parent i_mutexes, etc.
>
> where the i_mutexes would all be taken with mutex_trylock, and we'd just
> fail the whole setlease if any of them failed.
>
> ???
>
> --b.
next prev parent reply other threads:[~2011-06-12 19:10 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-10 0:09 lease/delegation/oplock semantics J. Bruce Fields
2011-06-10 0:10 ` [PATCH 1/2] locks: introduce i_blockleases to close lease races J. Bruce Fields
[not found] ` <20110610001011.GD22215-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
2011-06-10 0:11 ` [PATCH 2/2] locks: break lease on unlink J. Bruce Fields
2011-06-10 20:24 ` [PATCH 1/2] locks: introduce i_blockleases to close lease races Mimi Zohar
2011-06-10 21:34 ` J. Bruce Fields
2011-06-12 4:08 ` J. Bruce Fields
2011-06-12 19:10 ` Mimi Zohar [this message]
2011-06-12 19:12 ` J. Bruce Fields
[not found] ` <20110612191220.GK12149-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
2011-06-12 20:54 ` Mimi Zohar
2011-06-13 12:19 ` J. Bruce Fields
2011-06-13 20:37 ` Mimi Zohar
2011-06-14 0:35 ` J. Bruce Fields
[not found] ` <20110613121939.GL12149-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
2011-06-15 15:47 ` J. 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=1307905804.3564.28.camel@localhost.localdomain \
--to=zohar@linux.vnet.ibm.com \
--cc=bfields@fieldses.org \
--cc=eparis@redhat.com \
--cc=hch@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=samba-technical@lists.samba.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).