Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 161
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 09 5月, 2016 1 次提交
    • A
      nfs: per-name sillyunlink exclusion · 884be175
      由 Al Viro 提交于 
      use d_alloc_parallel() for sillyunlink/lookup exclusion and
explicit rwsem (nfs_rmdir() being a writer and nfs_call_unlink() -
a reader) for rmdir/sillyunlink one.

That ought to make lookup/readdir/!O_CREAT atomic_open really
parallel on NFS.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      884be175
  3. 03 5月, 2016 1 次提交
  5. 16 4月, 2015 1 次提交
  7. 18 3月, 2014 3 次提交
  9. 29 10月, 2013 1 次提交
  11. 25 10月, 2013 1 次提交
  13. 04 9月, 2013 1 次提交
  15. 22 8月, 2013 2 次提交
  17. 05 7月, 2013 1 次提交
  19. 23 2月, 2013 1 次提交
    • T
      NFS: Don't allow NFS silly-renamed files to be deleted, no signal · 5a7a613a
      由 Trond Myklebust 提交于 
      Commit 73ca1001 broke the code that prevents the client from deleting
a silly renamed dentry.  This affected "delete on last close"
semantics as after that commit, nothing prevented removal of
silly-renamed files.  As a result, a process holding a file open
could easily get an ESTALE on the file in a directory where some
other process issued 'rm -rf some_dir_containing_the_file' twice.
Before the commit, any attempt at unlinking silly renamed files would
fail inside may_delete() with -EBUSY because of the
DCACHE_NFSFS_RENAMED flag.  The following testcase demonstrates
the problem:
  tail -f /nfsmnt/dir/file &
  rm -rf /nfsmnt/dir
  rm -rf /nfsmnt/dir
  # second removal does not fail, 'tail' process receives ESTALE

The problem with the above commit is that it unhashes the old and
new dentries from the lookup path, even in the normal case when
a signal is not encountered and it would have been safe to call
d_move.  Unfortunately the old dentry has the special
DCACHE_NFSFS_RENAMED flag set on it.  Unhashing has the
side-effect that future lookups call d_alloc(), allocating a new
dentry without the special flag for any silly-renamed files.  As a
result, subsequent calls to unlink silly renamed files do not fail
but allow the removal to go through.  This will result in ESTALE
errors for any other process doing operations on the file.

To fix this, go back to using d_move on success.
For the signal case, it's unclear what we may safely do beyond d_drop.
Reported-by: NDave Wysochanski <dwysocha@redhat.com>
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
Acked-by: NJeff Layton <jlayton@redhat.com>
Cc: stable@vger.kernel.org
      5a7a613a
  21. 18 2月, 2013 1 次提交
  23. 01 2月, 2013 1 次提交
  25. 01 11月, 2012 1 次提交
    • W
      NFS: add nfs_sb_deactive_async to avoid deadlock · 324d003b
      由 Weston Andros Adamson 提交于 
      Use nfs_sb_deactive_async instead of nfs_sb_deactive when in a workqueue
context.  This avoids a deadlock where rpc_shutdown_client loops forever
in a workqueue kworker context, trying to kill all RPC tasks associated with
the client, while one or more of these tasks have already been assigned to the
same kworker (and will never run rpc_exit_task).

This approach is needed because RPC tasks that have already been assigned
to a kworker by queue_work cannot be canceled, as explained in the comment
for workqueue.c:insert_wq_barrier.
Signed-off-by: NWeston Andros Adamson <dros@netapp.com>
[Trond: add module_get/put.]
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      324d003b
  27. 29 6月, 2012 1 次提交
  29. 21 3月, 2012 2 次提交
  31. 12 3月, 2012 1 次提交
    • T
      NFS: Fix a number of sparse warnings · 17280175
      由 Trond Myklebust 提交于 
      Fix a number of "warning: symbol 'foo' was not declared. Should it be
static?" conditions.

Fix 2 cases of "warning: Using plain integer as NULL pointer"

fs/nfs/delegation.c:263:31: warning: restricted fmode_t degrades to integer
  - We want to allow upgrades to a WRITE delegation, but should otherwise
    consider servers that hand out duplicate delegations to be borken.
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      17280175
  33. 01 2月, 2012 1 次提交
  35. 20 10月, 2011 1 次提交
  37. 26 7月, 2011 1 次提交
    • J
      nfs: don't use d_move in nfs_async_rename_done · 73ca1001
      由 Jeff Layton 提交于 
      If the task that initiated the sillyrename ends up being killed by a
fatal signal, then it will eventually return back to userspace and end
up releasing the i_mutex. d_move however needs to be done while holding
the i_mutex.

Instead of using d_move here, just unhash the old and new dentries to
prevent them from being found by lookups. With this change though, the
dentries are now incorrect post-rename and do not reflect the actual
name of the file on the server. I'm proceeding under the assumption
that since they are unhashed that this isn't really a problem.

In order for the sillydelete to still work though, the dname must be
copied earlier when setting up the sillydelete info, and the name must
be recopied if the sillydelete info has to be moved to a new dentry.
Reported-by: NAl Viro <viro@ZenIV.linux.org.uk>
Signed-off-by: NJeff Layton <jlayton@redhat.com>
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      73ca1001
  39. 16 7月, 2011 1 次提交
  41. 17 3月, 2011 1 次提交
    • A
      nfs: store devname at disconnected NFS roots · b1942c5f
      由 Al Viro 提交于 
      part 2: make sure that disconnected roots have corresponding mnt_devname
values stashed into them.

Have nfs*_get_root() stuff a copy of devname into ->d_fsdata of the
found root, provided that it is disconnected.

Have ->d_release() free it when dentry goes away.

Have the places where NFS uses ->d_fsdata for sillyrename (and that
can *never* happen to a disconnected root - dentry will be attached
to its parent) free old devname copies if they find those.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      b1942c5f
  43. 11 3月, 2011 1 次提交
    • T
      SUNRPC: Close a race in __rpc_wait_for_completion_task() · bf294b41
      由 Trond Myklebust 提交于 
      Although they run as rpciod background tasks, under normal operation
(i.e. no SIGKILL), functions like nfs_sillyrename(), nfs4_proc_unlck()
and nfs4_do_close() want to be fully synchronous. This means that when we
exit, we want all references to the rpc_task to be gone, and we want
any dentry references etc. held by that task to be released.

For this reason these functions call __rpc_wait_for_completion_task(),
followed by rpc_put_task() in the expectation that the latter will be
releasing the last reference to the rpc_task, and thus ensuring that the
callback_ops->rpc_release() has been called synchronously.

This patch fixes a race which exists due to the fact that
rpciod calls rpc_complete_task() (in order to wake up the callers of
__rpc_wait_for_completion_task()) and then subsequently calls
rpc_put_task() without ensuring that these two steps are done atomically.

In order to avoid adding new spin locks, the patch uses the existing
waitqueue spin lock to order the rpc_task reference count releases between
the waiting process and rpciod.
The common case where nobody is waiting for completion is optimised for by
checking if the RPC_TASK_ASYNC flag is cleared and/or if the rpc_task
reference count is 1: in those cases we drop trying to grab the spin lock,
and immediately free up the rpc_task.

Those few processes that need to put the rpc_task from inside an
asynchronous context and that do not care about ordering are given a new
helper: rpc_put_task_async().
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      bf294b41
  45. 07 1月, 2011 1 次提交
  47. 22 12月, 2010 1 次提交
  49. 29 10月, 2010 1 次提交
  51. 24 9月, 2010 1 次提交
  53. 22 9月, 2010 1 次提交
  55. 18 9月, 2010 2 次提交
  57. 23 6月, 2010 1 次提交
  59. 15 5月, 2010 1 次提交
  61. 07 12月, 2009 1 次提交
  63. 06 12月, 2009 1 次提交
  65. 05 12月, 2009 1 次提交
  67. 18 6月, 2009 2 次提交