All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 0/3] Include OFD lock owners when looking up state
@ 2016-04-01 15:34 Benjamin Coddington
  2016-04-01 15:34 ` [PATCH 1/3] NFS: add get_nfs_lock_context, find_nfs_lock_context Benjamin Coddington
                   ` (4 more replies)
  0 siblings, 5 replies; 16+ messages in thread
From: Benjamin Coddington @ 2016-04-01 15:34 UTC (permalink / raw)
  To: Trond Myklebust, Anna Schumaker, Jeff Layton; +Cc: linux-nfs

The client sends IO only under the open stateid when using OFD (and flock)
locking instead of the appropriate lock stateid because the nfs_lock_context
only tracks POSIX lockowners, which is the reference to the process' file
table.

This is a problem for two reasons.  The first is that rfc7530,
section-9.1.4.5 states that IO sent by an entity corresponding to the
lock-owner which holds a byte-range lock should be sent under the lock
stateid for that lock.  Otherwise, a server enforcing mandatory byte-range
locking might reject that operation.  Secondly, not tracking OFD lock owners
means that accounting for IO sent under those owners is broken.  That
creates a problem for some work to guarantee an unlock will be sent after
operations scheduled under a lock complete.

To fix this, this set starts tracking the OFD lock owner within the
nfs_lock_context.  Unique nfs_lock_contexts are created on distinct
combinations of current->files, struct file, and pid.  In order to do this,
some re-arrangement of when to create or lookup the nfs_lock_context was
needed since the struct file pointer must be included during that creation
or lookup.

It is possible for a process to hold both an OFD and a POSIX lock on a file
as long as they do not conflict.  There would be two stateids that could be
selected for IO operations on that file.  In that case only the first
stateid found to match the current lock context will ever be used.  The
result of this is that mixed OFD and POSIX locks within the same process on
a server enforcing mandatory locking should be avoided.  The fix for this
probably would require a byte-range lookup of stateid when scheduling an IO
operation, and the ability to split IO that crossed lock ranges with
different owners.

Comments and critique is welcomed.

Benjamin Coddington (3):
  NFS: add get_nfs_lock_context, find_nfs_lock_context
  NFS: add OFD lock owners to nfs_lock_context
  NFSv4: use OFD lock owners in lock state lookup

 fs/nfs/direct.c          |    8 ++++----
 fs/nfs/file.c            |    2 +-
 fs/nfs/fscache-index.c   |    4 ++--
 fs/nfs/fscache.h         |   12 ++++++------
 fs/nfs/inode.c           |   32 ++++++++++++++++++++++----------
 fs/nfs/nfs42proc.c       |    8 ++++----
 fs/nfs/nfs4proc.c        |    3 ++-
 fs/nfs/nfs4state.c       |   21 ++++++++++++---------
 fs/nfs/pagelist.c        |   22 ++++++++--------------
 fs/nfs/read.c            |   38 +++++++++++++++++++++++---------------
 fs/nfs/write.c           |   17 ++++++++++-------
 include/linux/nfs_fs.h   |    8 +++++---
 include/linux/nfs_page.h |    2 +-
 13 files changed, 100 insertions(+), 77 deletions(-)


^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, other threads:[~2016-04-01 20:24 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-04-01 15:34 [PATCH 0/3] Include OFD lock owners when looking up state Benjamin Coddington
2016-04-01 15:34 ` [PATCH 1/3] NFS: add get_nfs_lock_context, find_nfs_lock_context Benjamin Coddington
2016-04-01 16:45   ` kbuild test robot
2016-04-01 17:03   ` kbuild test robot
2016-04-01 15:34 ` [PATCH 2/3] NFS: add OFD lock owners to nfs_lock_context Benjamin Coddington
2016-04-01 16:17   ` kbuild test robot
2016-04-01 16:55   ` kbuild test robot
2016-04-01 15:34 ` [PATCH 3/3] NFSv4: use OFD lock owners in lock state lookup Benjamin Coddington
2016-04-01 15:47 ` [PATCH 0/3] Include OFD lock owners when looking up state Trond Myklebust
2016-04-01 15:48   ` Benjamin Coddington
2016-04-01 16:09     ` Trond Myklebust
2016-04-01 16:19       ` Jeff Layton
2016-04-01 20:24         ` Frank Filz
2016-04-01 16:35       ` Benjamin Coddington
2016-04-01 16:09   ` Jeff Layton
2016-04-01 17:17 ` Benjamin Coddington

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.