Revision tags: v3.12-rc4, v3.12-rc3, v3.12-rc2, v3.12-rc1 |
|
#
6de1472f |
| 16-Sep-2013 |
Al Viro <viro@zeniv.linux.org.uk> |
nfs: use %p[dD] instead of open-coded (and often racy) equivalents
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
|
Revision tags: v3.11 |
|
#
ba6c0592 |
| 30-Aug-2013 |
Trond Myklebust <Trond.Myklebust@netapp.com> |
NFS: Ensure that rmdir() waits for sillyrenames to complete
If an NFS client does
mkdir("dir"); fd = open("dir/file"); unlink("dir/file"); close(fd); rmdir("dir");
then the asynchronous natur
NFS: Ensure that rmdir() waits for sillyrenames to complete
If an NFS client does
mkdir("dir"); fd = open("dir/file"); unlink("dir/file"); close(fd); rmdir("dir");
then the asynchronous nature of the sillyrename operation means that we can end up getting EBUSY for the rmdir() in the above test. Fix that by ensuring that we wait for any in-progress sillyrenames before sending the rmdir() to the server.
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
show more ...
|
Revision tags: v3.11-rc7 |
|
#
70ded201 |
| 21-Aug-2013 |
Trond Myklebust <Trond.Myklebust@netapp.com> |
NFS: Add tracepoints for debugging NFS rename and sillyrename issues
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
|
#
c2dd1378 |
| 21-Aug-2013 |
Trond Myklebust <Trond.Myklebust@netapp.com> |
NFS: Clean up nfs_sillyrename()
Optimise for the case where we only do one lookup. Clean up the code so it is obvious that silly[] is not a dynamic array.
Signed-off-by: Trond Myklebust <Trond.Mykl
NFS: Clean up nfs_sillyrename()
Optimise for the case where we only do one lookup. Clean up the code so it is obvious that silly[] is not a dynamic array.
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
show more ...
|
Revision tags: v3.11-rc6, v3.11-rc5, v3.11-rc4, v3.11-rc3, v3.11-rc2, v3.11-rc1 |
|
#
84d08fa8 |
| 05-Jul-2013 |
Al Viro <viro@zeniv.linux.org.uk> |
helper for reading ->d_count
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
|
Revision tags: v3.10, v3.10-rc7, v3.10-rc6, v3.10-rc5, v3.10-rc4, v3.10-rc3, v3.10-rc2, v3.10-rc1, v3.9, v3.9-rc8, v3.9-rc7, v3.9-rc6, v3.9-rc5, v3.9-rc4, v3.9-rc3, v3.9-rc2, v3.9-rc1 |
|
#
5a7a613a |
| 22-Feb-2013 |
Trond Myklebust <Trond.Myklebust@netapp.com> |
NFS: Don't allow NFS silly-renamed files to be deleted, no signal
Commit 73ca100 broke the code that prevents the client from deleting a silly renamed dentry. This affected "delete on last close" s
NFS: Don't allow NFS silly-renamed files to be deleted, no signal
Commit 73ca100 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: Dave Wysochanski <dwysocha@redhat.com> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com> Acked-by: Jeff Layton <jlayton@redhat.com> Cc: stable@vger.kernel.org
show more ...
|
Revision tags: v3.8 |
|
#
96aa1549 |
| 12-Feb-2013 |
Tim Gardner <tim.gardner@canonical.com> |
nfs: remove kfree() redundant null checks
smatch analysis:
fs/nfs/getroot.c:130 nfs_get_root() info: redundant null check on name calling kfree()
fs/nfs/unlink.c:272 nfs_async_unlink() info: redu
nfs: remove kfree() redundant null checks
smatch analysis:
fs/nfs/getroot.c:130 nfs_get_root() info: redundant null check on name calling kfree()
fs/nfs/unlink.c:272 nfs_async_unlink() info: redundant null check on devname_garbage calling kfree()
Cc: Trond Myklebust <Trond.Myklebust@netapp.com> Cc: linux-nfs@vger.kernel.org Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
show more ...
|
Revision tags: v3.8-rc7, v3.8-rc6, v3.8-rc5, v3.8-rc4 |
|
#
322b2b90 |
| 11-Jan-2013 |
Trond Myklebust <Trond.Myklebust@netapp.com> |
Revert "NFS: add nfs_sb_deactive_async to avoid deadlock"
This reverts commit 324d003b0cd82151adbaecefef57b73f7959a469.
The deadlock turned out to be caused by a workqueue limitation that has now b
Revert "NFS: add nfs_sb_deactive_async to avoid deadlock"
This reverts commit 324d003b0cd82151adbaecefef57b73f7959a469.
The deadlock turned out to be caused by a workqueue limitation that has now been worked around in the RPC code (see comment in rpc_free_task).
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
show more ...
|
Revision tags: v3.8-rc3, v3.8-rc2, v3.8-rc1, v3.7, v3.7-rc8, v3.7-rc7, v3.7-rc6, v3.7-rc5, v3.7-rc4 |
|
#
324d003b |
| 30-Oct-2012 |
Weston Andros Adamson <dros@netapp.com> |
NFS: add nfs_sb_deactive_async to avoid deadlock
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
NFS: add nfs_sb_deactive_async to avoid deadlock
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: Weston Andros Adamson <dros@netapp.com> [Trond: add module_get/put.] Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
show more ...
|
Revision tags: v3.7-rc3, v3.7-rc2, v3.7-rc1, v3.6, v3.6-rc7, v3.6-rc6, v3.6-rc5, v3.6-rc4, v3.6-rc3, v3.6-rc2, v3.6-rc1, v3.5, v3.5-rc7, v3.5-rc6, v3.5-rc5, v3.5-rc4 |
|
#
57ec14c5 |
| 20-Jun-2012 |
Bryan Schumaker <bjschuma@netapp.com> |
NFS: Create a return_delegation rpc op
Delegations are a v4 feature, so push return_delegation out of the generic client by creating a new rpc_op and renaming the old function to be in the nfs v4 "n
NFS: Create a return_delegation rpc op
Delegations are a v4 feature, so push return_delegation out of the generic client by creating a new rpc_op and renaming the old function to be in the nfs v4 "namespace"
Signed-off-by: Bryan Schumaker <bjschuma@netapp.com> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
show more ...
|
Revision tags: v3.5-rc3, v3.5-rc2, v3.5-rc1, v3.4, v3.4-rc7, v3.4-rc6, v3.4-rc5, v3.4-rc4, v3.4-rc3, v3.4-rc2, v3.4-rc1 |
|
#
c6bfa1a1 |
| 19-Mar-2012 |
Bryan Schumaker <bjschuma@netapp.com> |
NFS: Remove nfs4_setup_sequence from generic rename code
This is an NFS v4 specific operation, so it belongs in the NFS v4 code and not the generic client.
Signed-off-by: Bryan Schumaker <bjschuma@
NFS: Remove nfs4_setup_sequence from generic rename code
This is an NFS v4 specific operation, so it belongs in the NFS v4 code and not the generic client.
Signed-off-by: Bryan Schumaker <bjschuma@netapp.com> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
show more ...
|
#
34e137cc |
| 19-Mar-2012 |
Bryan Schumaker <bjschuma@netapp.com> |
NFS: Remove nfs4_setup_sequence from generic unlink code
This is an NFS v4 specific operation, so it belongs in the NFS v4 code and not the generic client.
Signed-off-by: Bryan Schumaker <bjschuma@
NFS: Remove nfs4_setup_sequence from generic unlink code
This is an NFS v4 specific operation, so it belongs in the NFS v4 code and not the generic client.
Signed-off-by: Bryan Schumaker <bjschuma@netapp.com> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
show more ...
|
Revision tags: v3.3 |
|
#
17280175 |
| 11-Mar-2012 |
Trond Myklebust <Trond.Myklebust@netapp.com> |
NFS: Fix a number of sparse warnings
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
NFS: Fix a number of sparse warnings
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: Trond Myklebust <Trond.Myklebust@netapp.com>
show more ...
|
Revision tags: v3.3-rc7, v3.3-rc6, v3.3-rc5, v3.3-rc4, v3.3-rc3, v3.3-rc2, v3.3-rc1 |
|
#
9d12b216 |
| 17-Jan-2012 |
Trond Myklebust <Trond.Myklebust@netapp.com> |
NFSv41: Add a new helper nfs4_init_sequence()
Clean up
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
|
Revision tags: v3.2, v3.2-rc7, v3.2-rc6, v3.2-rc5, v3.2-rc4, v3.2-rc3, v3.2-rc2, v3.2-rc1, v3.1 |
|
#
d00c5d43 |
| 19-Oct-2011 |
Trond Myklebust <Trond.Myklebust@netapp.com> |
NFS: Get rid of nfs_restart_rpc()
It can trivially be replaced with rpc_restart_call_prepare.
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
|
Revision tags: v3.1-rc10, v3.1-rc9, v3.1-rc8, v3.1-rc7, v3.1-rc6, v3.1-rc5, v3.1-rc4, v3.1-rc3, v3.1-rc2, v3.1-rc1, v3.0 |
|
#
73ca1001 |
| 18-Jul-2011 |
Jeff Layton <jlayton@redhat.com> |
nfs: don't use d_move in nfs_async_rename_done
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 releasin
nfs: don't use d_move in nfs_async_rename_done
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: Al Viro <viro@ZenIV.linux.org.uk> Signed-off-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
show more ...
|
#
674e405b |
| 15-Jul-2011 |
J. Bruce Fields <bfields@redhat.com> |
nfs: document nfsv4 sillyrename issues
Somebody working on this code asked what the deal was with NFSv4, since this comment notes that it's v2/v3's statelessness that requires sillyrename. Shouldn'
nfs: document nfsv4 sillyrename issues
Somebody working on this code asked what the deal was with NFSv4, since this comment notes that it's v2/v3's statelessness that requires sillyrename. Shouldn't hurt to document the answer.
Signed-off-by: J. Bruce Fields <bfields@redhat.com> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
show more ...
|
Revision tags: v3.0-rc7, v3.0-rc6, v3.0-rc5, v3.0-rc4, v3.0-rc3, v3.0-rc2, v3.0-rc1, v2.6.39, v2.6.39-rc7, v2.6.39-rc6, v2.6.39-rc5, v2.6.39-rc4, v2.6.39-rc3, v2.6.39-rc2, v2.6.39-rc1 |
|
#
b1942c5f |
| 16-Mar-2011 |
Al Viro <viro@zeniv.linux.org.uk> |
nfs: store devname at disconnected NFS roots
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
nfs: store devname at disconnected NFS roots
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: Al Viro <viro@zeniv.linux.org.uk>
show more ...
|
Revision tags: v2.6.38, v2.6.38-rc8, v2.6.38-rc7, v2.6.38-rc6 |
|
#
bf294b41 |
| 21-Feb-2011 |
Trond Myklebust <Trond.Myklebust@netapp.com> |
SUNRPC: Close a race in __rpc_wait_for_completion_task()
Although they run as rpciod background tasks, under normal operation (i.e. no SIGKILL), functions like nfs_sillyrename(), nfs4_proc_unlck() a
SUNRPC: Close a race in __rpc_wait_for_completion_task()
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: Trond Myklebust <Trond.Myklebust@netapp.com>
show more ...
|
Revision tags: v2.6.38-rc5, v2.6.38-rc4, v2.6.38-rc3, v2.6.38-rc2, v2.6.38-rc1 |
|
#
b7ab39f6 |
| 07-Jan-2011 |
Nick Piggin <npiggin@kernel.dk> |
fs: dcache scale dentry refcount
Make d_count non-atomic and protect it with d_lock. This allows us to ensure a 0 refcount dentry remains 0 without dcache_lock. It is also fairly natural when we sta
fs: dcache scale dentry refcount
Make d_count non-atomic and protect it with d_lock. This allows us to ensure a 0 refcount dentry remains 0 without dcache_lock. It is also fairly natural when we start protecting many other dentry members with d_lock.
Signed-off-by: Nick Piggin <npiggin@kernel.dk>
show more ...
|
Revision tags: v2.6.37, v2.6.37-rc8, v2.6.37-rc7 |
|
#
1174dd1f |
| 21-Dec-2010 |
Trond Myklebust <Trond.Myklebust@netapp.com> |
NFSv4: Convert a few commas into semicolons...
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
|
Revision tags: v2.6.37-rc6, v2.6.37-rc5, v2.6.37-rc4, v2.6.37-rc3, v2.6.37-rc2, v2.6.37-rc1 |
|
#
a4118ee1 |
| 27-Oct-2010 |
Al Viro <viro@zeniv.linux.org.uk> |
a couple of open-coded ihold() introduced by nfs merge
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
|
Revision tags: v2.6.36, v2.6.36-rc8, v2.6.36-rc7, v2.6.36-rc6 |
|
#
dfb4f309 |
| 24-Sep-2010 |
Benny Halevy <bhalevy@panasas.com> |
NFSv4.1: keep seq_res.sr_slot as pointer rather than an index
Having to explicitly initialize sr_slotid to NFS4_MAX_SLOT_TABLE resulted in numerous bugs. Keeping the current slot as a pointer to th
NFSv4.1: keep seq_res.sr_slot as pointer rather than an index
Having to explicitly initialize sr_slotid to NFS4_MAX_SLOT_TABLE resulted in numerous bugs. Keeping the current slot as a pointer to the slot table is more straight forward and robust as it's implicitly set up to NULL wherever the seq_res member is initialized to zeroes.
Signed-off-by: Benny Halevy <bhalevy@panasas.com> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
show more ...
|
#
f7732d65 |
| 21-Sep-2010 |
Trond Myklebust <Trond.Myklebust@netapp.com> |
NFS: Fix a use-after-free case in nfs_async_rename()
The call to nfs_async_rename_release() after rpc_run_task() is incorrect. The rpc_run_task() is always guaranteed to call the ->rpc_release() met
NFS: Fix a use-after-free case in nfs_async_rename()
The call to nfs_async_rename_release() after rpc_run_task() is incorrect. The rpc_run_task() is always guaranteed to call the ->rpc_release() method.
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
show more ...
|
Revision tags: v2.6.36-rc5 |
|
#
d3d4152a |
| 17-Sep-2010 |
Jeff Layton <jlayton@redhat.com> |
nfs: make sillyrename an async operation
A synchronous rename can be interrupted by a SIGKILL. If that happens during a sillyrename operation, it's possible for the rename call to be sent to the ser
nfs: make sillyrename an async operation
A synchronous rename can be interrupted by a SIGKILL. If that happens during a sillyrename operation, it's possible for the rename call to be sent to the server, but the task exits before processing the reply. If this happens, the sillyrenamed file won't get cleaned up during nfs_dentry_iput and the server is left with a dangling .nfs* file hanging around.
Fix this problem by turning sillyrename into an asynchronous operation and have the task doing the sillyrename just wait on the reply. If the task is killed before the sillyrename completes, it'll still proceed to completion.
Signed-off-by: Jeff Layton <jlayton@redhat.com> Reviewed-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
show more ...
|