From: "J. Bruce Fields" <bfields@fieldses.org>
To: Mimi Zohar <zohar@linux.vnet.ibm.com>
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: Wed, 15 Jun 2011 11:47:51 -0400 [thread overview]
Message-ID: <20110615154751.GA5467@fieldses.org> (raw)
In-Reply-To: <20110613121939.GL12149@fieldses.org>
On Mon, Jun 13, 2011 at 08:19:39AM -0400, J. Bruce Fields wrote:
> On Sun, Jun 12, 2011 at 04:54:33PM -0400, Mimi Zohar wrote:
> > You're adding a call to break_lease() for each of them. Currently
> > __break_lease() is only called if a lease exists. Assuming there aren't
> > any existing leases, couldn't break_lease() call something like
> > block_lease()? The free would be after the link, unlink, ...,
> > completed/failed.
> >
> > (You wouldn't actually need to alloc/free the 'struct file_lock' each
> > time, just set the pointer and reset to NULL.)
>
> Well, the pointer has to be set to something. I suppose we could put a
> struct file_lock on the stack.
The locking code is under a global spinlock--instead of an atomic inc
and dec of inode->i_blockleases we'd be doing a pair of lock/unlocks of
file_lock_lock.
We could probably fix that: off the top of my head the only reason I see
for a global lock is the stupid deadlock-detection code. Which is only
needed for posix locks (and I'm not at all convinced it's needed even
there).
With that fixed, it would be a choice between an i_lock-protected
list_add/list_del vs. an atomic inc/dec of a new inode field.
--b.
WARNING: multiple messages have this Message-ID (diff)
From: "J. Bruce Fields" <bfields-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
To: Mimi Zohar <zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
Cc: linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
samba-technical-w/Ol4Ecudpl8XjKLYN78aQ@public.gmane.org,
Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>,
Eric Paris <eparis-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Subject: Re: [PATCH 1/2] locks: introduce i_blockleases to close lease races
Date: Wed, 15 Jun 2011 11:47:51 -0400 [thread overview]
Message-ID: <20110615154751.GA5467@fieldses.org> (raw)
In-Reply-To: <20110613121939.GL12149-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
On Mon, Jun 13, 2011 at 08:19:39AM -0400, J. Bruce Fields wrote:
> On Sun, Jun 12, 2011 at 04:54:33PM -0400, Mimi Zohar wrote:
> > You're adding a call to break_lease() for each of them. Currently
> > __break_lease() is only called if a lease exists. Assuming there aren't
> > any existing leases, couldn't break_lease() call something like
> > block_lease()? The free would be after the link, unlink, ...,
> > completed/failed.
> >
> > (You wouldn't actually need to alloc/free the 'struct file_lock' each
> > time, just set the pointer and reset to NULL.)
>
> Well, the pointer has to be set to something. I suppose we could put a
> struct file_lock on the stack.
The locking code is under a global spinlock--instead of an atomic inc
and dec of inode->i_blockleases we'd be doing a pair of lock/unlocks of
file_lock_lock.
We could probably fix that: off the top of my head the only reason I see
for a global lock is the stupid deadlock-detection code. Which is only
needed for posix locks (and I'm not at all convinced it's needed even
there).
With that fixed, it would be a choice between an i_lock-protected
list_add/list_del vs. an atomic inc/dec of a new inode field.
--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2011-06-15 15:47 UTC|newest]
Thread overview: 19+ 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:09 ` J. Bruce Fields
2011-06-10 0:10 ` [PATCH 1/2] locks: introduce i_blockleases to close lease races J. Bruce Fields
2011-06-10 0:11 ` [PATCH 2/2] locks: break lease on unlink J. Bruce Fields
2011-06-10 0:11 ` 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
2011-06-12 19:12 ` J. Bruce Fields
2011-06-12 20:54 ` Mimi Zohar
2011-06-12 20:54 ` Mimi Zohar
2011-06-13 12:19 ` J. Bruce Fields
2011-06-13 12:19 ` J. Bruce Fields
2011-06-13 20:37 ` Mimi Zohar
2011-06-13 20:37 ` Mimi Zohar
2011-06-14 0:35 ` J. Bruce Fields
2011-06-15 15:47 ` J. Bruce Fields [this message]
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=20110615154751.GA5467@fieldses.org \
--to=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 \
--cc=zohar@linux.vnet.ibm.com \
/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.