From: Jeff Layton <jlayton@primarydata.com>
To: linux-fsdevel@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, Al Viro <viro@ZenIV.linux.org.uk>,
Christoph Hellwig <hch@infradead.org>,
bfields@fieldses.org
Subject: [RFC PATCH 00/12] locks: saner method for managing file locks
Date: Wed, 10 Sep 2014 10:28:38 -0400 [thread overview]
Message-ID: <1410359330-27564-1-git-send-email-jlayton@primarydata.com> (raw)
We currently manage all file_locks via a singly-linked list. This is
problematic for a number of reasons:
- we have to protect all file locks with the same spinlock (or
equivalent). Currently that uses the i_lock, but Christoph has voiced
objections due to the potential for contention with other i_lock
users. He'd like to see us move to using a different lock.
- we have to walk through irrelevant file locks in order to get to the
ones we're interested in. For instance, POSIX locks are at the end
of the list, so we have to skip over all of the flock locks and
leases before we can work with them.
- the singly-linked list is primitive and difficult to work with. We
have to keep track of the "before" pointer and it's easy to get that
wrong.
Cleaning all of this up is complicated by the fact that no one really
wants to grow struct inode in order to do so. We have a single pointer
in the inode now and I don't think we want to use any more.
One possibility that Trond raised was to move this to an hlist, but
that doesn't do anything about the desire for a new spinlock.
This patchset takes the approach of replacing the i_flock list with a
new struct file_lock_context that is allocated when we intend to add a
new file lock to an inode. The file_lock_context is only freed when we
destroy the inode.
Within that, we have separate (and standard!) lists for each lock type,
and a dedicated spinlock for managing those lists. In principle we could
even consider adding separate locks for each, but I didn't bother with
that for now.
For now, the code is still pretty "raw" and isn't bisectable. This is
just a RFC for the basic approach. This is probably v3.19 material at
best.
Anyone have thoughts or comments on the basic approach?
Jeff Layton (12):
locks: add a new struct file_locking_context pointer to struct inode
locks: add new struct list_head to struct file_lock
locks: have locks_release_file use flock_lock_file to release generic
flock locks
locks: move flock locks to file_lock_context
locks: convert posix locks to file_lock_context
locks: convert lease handling to file_lock_context
ceph: convert to looking for locks in struct file_lock_context
nfs: convert lock handling to use file_lock_context
cifs: convert it to use file_lock_context
lockd: convert it to use file_lock_context
nfsd: convert to file_lock_context
locks: remove i_flock field from struct inode
fs/ceph/locks.c | 45 +++--
fs/ceph/mds_client.c | 4 -
fs/cifs/file.c | 34 ++--
fs/inode.c | 3 +-
fs/lockd/svcsubs.c | 26 ++-
fs/locks.c | 504 ++++++++++++++++++++++++++-------------------------
fs/nfs/delegation.c | 37 ++--
fs/nfs/nfs4state.c | 24 ++-
fs/nfs/pagelist.c | 3 +-
fs/nfs/write.c | 39 +++-
fs/nfsd/nfs4state.c | 18 +-
fs/read_write.c | 2 +-
include/linux/fs.h | 25 ++-
13 files changed, 425 insertions(+), 339 deletions(-)
--
1.9.3
next reply other threads:[~2014-09-10 14:28 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-10 14:28 Jeff Layton [this message]
2014-09-10 14:28 ` [RFC PATCH 01/12] locks: add a new struct file_locking_context pointer to struct inode Jeff Layton
2014-09-10 18:38 ` J. Bruce Fields
2014-09-10 18:51 ` Jeff Layton
2014-09-10 14:28 ` [RFC PATCH 02/12] locks: add new struct list_head to struct file_lock Jeff Layton
2014-09-10 14:28 ` [RFC PATCH 03/12] locks: have locks_release_file use flock_lock_file to release generic flock locks Jeff Layton
2014-09-10 17:38 ` J. Bruce Fields
2014-09-10 17:49 ` Jeff Layton
2014-09-10 14:28 ` [RFC PATCH 04/12] locks: move flock locks to file_lock_context Jeff Layton
2014-09-10 14:28 ` [RFC PATCH 05/12] locks: convert posix " Jeff Layton
2014-09-10 14:28 ` [RFC PATCH 06/12] locks: convert lease handling " Jeff Layton
2014-09-10 14:28 ` [RFC PATCH 07/12] ceph: convert to looking for locks in struct file_lock_context Jeff Layton
2014-09-10 14:28 ` [RFC PATCH 08/12] nfs: convert lock handling to use file_lock_context Jeff Layton
2014-09-10 19:17 ` J. Bruce Fields
2014-09-10 19:20 ` Al Viro
2014-09-10 19:28 ` Jeff Layton
2014-09-10 19:34 ` J. Bruce Fields
2014-09-10 14:28 ` [RFC PATCH 09/12] cifs: convert it " Jeff Layton
2014-09-10 14:28 ` [RFC PATCH 10/12] lockd: " Jeff Layton
2014-09-10 14:28 ` [RFC PATCH 11/12] nfsd: convert to file_lock_context Jeff Layton
2014-09-10 14:28 ` [RFC PATCH 12/12] locks: remove i_flock field from struct inode Jeff Layton
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=1410359330-27564-1-git-send-email-jlayton@primarydata.com \
--to=jlayton@primarydata.com \
--cc=bfields@fieldses.org \
--cc=hch@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.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 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).