- 13 Aug, 2018 3 commits
-
-
Trond Myklebust authored
The back channel size is allowed to be 1 or greater. Signed-off-by:
Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by:
Anna Schumaker <Anna.Schumaker@Netapp.com>
-
Trond Myklebust authored
Catch the ERESTARTSYS error so that it can be processed by the callers. Signed-off-by:
-
Olga Kornievskaia authored
Mark the destination state to indicate a server-side copy is happening. On detecting a reboot and recovering open state check if any state is engaged in a server-side copy, if so, find the copy and mark it and then signal the waiting thread. Upon wakeup, if copy was marked then propage EAGAIN to the nfsd_copy_file_range and restart the copy from scratch. Signed-off-by:
Olga Kornievskaia <kolga@netapp.com> Signed-off-by:
-
- 09 Aug, 2018 9 commits
-
-
Olga Kornievskaia authored
A COPY with unstable write data needs a simple sync commit. Filehandle value is gotten as a part of the inner loop so in case of a reboot retry it should get the new value. Signed-off-by:
-
Olga Kornievskaia authored
If client sent async COPY and server replied with ERR_OFFLOAD_NO_REQS, client should retry with a synchronous copy. Signed-off-by:
-
Olga Kornievskaia authored
When COPY is killed by the user send OFFLOAD_CANCEL to server processing the copy. Signed-off-by:
-
Olga Kornievskaia authored
Make this function available to nfs42proc.c Signed-off-by:
-
Olga Kornievskaia authored
It's possible that server replies back with CB_OFFLOAD call and COPY reply at the same time such that client will process CB_OFFLOAD before reply to COPY. For that keep a list of pending callback stateids received and then before waiting on completion check the pending list. Cleanup any pending copies on the client shutdown. Signed-off-by:
-
Olga Kornievskaia authored
Change xdr to always send COPY asynchronously. Keep the list copies send in a list under a server structure. Once copy is sent, it waits on a completion structure that will be signalled by the callback thread that receives CB_OFFLOAD. If CB_OFFLOAD returned an error and even if it returned partial bytes, ignore them (as we can't commit without a verifier to match) and return an error. Signed-off-by:
-
Olga Kornievskaia authored
If server returns async reply, it must include a callback stateid, wr_callback_id in the write_response4. Signed-off-by:
-
Olga Kornievskaia authored
Signed-off-by:
-
Olga Kornievskaia authored
Signed-off-by:
-
- 08 Aug, 2018 10 commits
-
-
NeilBrown authored
When a direct-write completes, a work_struct is schedule to handle the completion. When NFS is being used for swap, the direct write might be a swap-out, so memory allocation can block until the write completes. The work queue currently used is not WQ_MEM_RECLAIM, so tasks can block waiting for memory - this leads to deadlock. So use nfsiod_workqueue instead. This will always have a running thread, and work items should never block waiting for memory. Signed-off-by:
Neil Brown <neilb@suse.com> Signed-off-by:
-
Wei Yongjun authored
Error code is set in the error handling cases but never used. Fix it. Fixes: 937e3133 ("NFSv4.1: Ensure we clear the SP4_MACH_CRED flags in nfs4_sp4_select_mode()") Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by:
-
Gustavo A. R. Silva authored
Return statements in functions returning bool should use true or false instead of an integer value. This issue was detected with the help of Coccinelle. Signed-off-by:
Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by:
-
Trond Myklebust authored
Layout segment validity is determined only by the NFS_LSEG_VALID flag. If it is set, the layout segment is finable. As it is, when the flexfiles driver sets NFS_LSEG_LAYOUTRETURN to indicate that we cannot discard the layout segment, but that it must be returned, then this can result in an unnecessary layoutget storm. Signed-off-by:
-
Gustavo A. R. Silva authored
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Warning level 2 was used: -Wimplicit-fallthrough=2 Signed-off-by:
-
Trond Myklebust authored
When we update the change attribute, we should also clear the flag that says it is out of date. Signed-off-by:
-
Trond Myklebust authored
If the object being renamed from one directory to another is also a directory, then 'nlink' will change for both directories. Signed-off-by:
-
Trond Myklebust authored
Ensure that we always bump or drop the nlink count on the parent directory when we do a mkdir or a rmdir(). This needs to be done by hand as we don't have pre/post op attributes. Signed-off-by:
-
Trond Myklebust authored
If the server tells us that out layoutreturn raced with another layout update, then we must ensure that the new layout segments are not in use before we resend with an updated layout stateid. Signed-off-by:
-
Chuck Lever authored
I found that injecting disconnects with v4.18-rc resulted in random failures of the multi-threaded git regression test. The root cause appears to be that, after a reconnect, the RPC/RDMA transport is waking pending RPCs before the transport has posted enough Receive buffers to receive the Replies. If a Reply arrives before enough Receive buffers are posted, the connection is dropped. A few connection drops happen in quick succession as the client and server struggle to regain credit synchronization. This regression was introduced with commit 7c8d9e7c ("xprtrdma: Move Receive posting to Receive handler"). The client is supposed to post a single Receive when a connection is established because it's not supposed to send more than one RPC Call before it gets a fresh credit grant in the first RPC Reply [RFC 8166, Section 3.3.3]. Unfortunately there appears to be a longstanding bug in the Linux client's credit accounting mechanism. On connect, it simply dumps all pending RPC Calls onto the new connection. It's possible it has done this ever since the RPC/RDMA transport was added to the kernel ten years ago. Servers have so far been tolerant of this bad behavior. Currently no server implementation ever changes its credit grant over reconnects, and servers always repost enough Receives before connections are fully established. The Linux client implementation used to post a Receive before each of these Calls. This has covered up the flooding send behavior. I could try to correct this old bug so that the client sends exactly one RPC Call and waits for a Reply. Since we are so close to the next merge window, I'm going to instead provide a simple patch to post enough Receives before a reconnect completes (based on the number of credits granted to the previous connection). The spurious disconnects will be gone, but the client will still send multiple RPC Calls immediately after a reconnect. Addressing the latter problem will wait for a merge window because a) I expect it to be a large change requiring lots of testing, and b) obviously the Linux client has interoperated successfully since day zero while still being broken. Fixes: 7c8d9e7c ("xprtrdma: Move Receive posting to ... ") Cc: stable@vger.kernel.org # v4.18+ Signed-off-by:
Chuck Lever <chuck.lever@oracle.com> Signed-off-by:
-
- 31 Jul, 2018 6 commits
-
-
Stephen Hemminger authored
Remove trailing whitespace and blank line at EOF Signed-off-by:
Stephen Hemminger <stephen@networkplumber.org> Signed-off-by:
-
Bill Baker authored
After a live data migration event at the NFS server, the client may send I/O requests to the wrong server, causing a live hang due to repeated recovery events. On the wire, this will appear as an I/O request failing with NFS4ERR_BADSESSION, followed by successful CREATE_SESSION, repeatedly. NFS4ERR_BADSSESSION is returned because the session ID being used was issued by the other server and is not valid at the old server. The failure is caused by async worker threads having cached the transport (xprt) in the rpc_task structure. After the migration recovery completes, the task is redispatched and the task resends the request to the wrong server based on the old value still present in tk_xprt. The solution is to recompute the tk_xprt field of the rpc_task structure so that the request goes to the correct server. Signed-off-by:
Bill Baker <bill.baker@oracle.com> Reviewed-by:
Helen Chao <helen.chao@oracle.com> Fixes: fb43d172 ("SUNRPC: Use the multipath iterator to assign a ...") Cc: stable@vger.kernel.org # v4.9+ Signed-off-by:
-
Olga Kornievskaia authored
If there is an error during processing of a callback message, it leads to refrence leak on the client structure and eventually an unclean superblock. Signed-off-by:
-
Dan Carpenter authored
Smatch complains that "num" can be uninitialized when kstrtoul() returns -ERANGE. It's true enough, but basically harmless in this case. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Dan Carpenter authored
kstrtoul() can return -ERANGE so Smatch complains that "num" can be uninitialized. We check that it's within bounds so it's not a huge deal. Signed-off-by:
-
Dave Wysochanski authored
The existing rpc_print_iostats has a few shortcomings. First, the naming is not consistent with other functions in the kernel that display stats. Second, it is really displaying stats for an rpc_clnt structure as it displays both xprt stats and per-op stats. Third, it does not handle rpc_clnt clones, which is important for the one in-kernel tree caller of this function, the NFS client's nfs_show_stats function. Fix all of the above by renaming the rpc_print_iostats to rpc_clnt_show_stats and looping through any rpc_clnt clones via cl_parent. Once this interface is fixed, this addresses a problem with NFSv4. Before this patch, the /proc/self/mountstats always showed incorrect counts for NFSv4 lease and session related opcodes such as SEQUENCE, RENEW, SETCLIENTID, CREATE_SESSION, etc. These counts were always 0 even though many ops would go over the wire. The reason for this is there are multiple rpc_clnt structures allocated for any given NFSv4 mount, and inside nfs_show_stats() we callled into rpc_print_iostats() which only handled one of them, nfs_server->client. Fix these counts by calling sunrpc's new rpc_clnt_show_stats() function, which handles cloned rpc_clnt structs and prints the stats together. Note that one side-effect of the above is that multiple mounts from the same NFS server will show identical counts in the above ops due to the fact the one rpc_clnt (representing the NFSv4 client state) is shared across mounts. Signed-off-by:
Dave Wysochanski <dwysocha@redhat.com> Signed-off-by:
-
- 30 Jul, 2018 8 commits
-
-
Dave Wysochanski authored
Add a helper function to add the metrics in two rpc_iostats structures. Signed-off-by:
-
Dave Wysochanski authored
Refactor the output of the metrics for one RPC op into an internal function. No functional change. Signed-off-by:
-
Sargun Dhillon authored
This turns rpc_auth_create_args into a const as it gets passed through the auth stack. Signed-off-by:
Sargun Dhillon <sargun@sargun.me> Signed-off-by:
-
Dan Carpenter authored
"dev->nr_children" is the number of children which were parsed successfully in bl_parse_stripe(). It could be all of them and then, in that case, it is equal to v->stripe.volumes_count. Either way, the > should be >= so that we don't go beyond the end of what we're supposed to. Fixes: 5c83746a ("pnfs/blocklayout: in-kernel GETDEVICEINFO XDR parsing") Signed-off-by:
Christoph Hellwig <hch@lst.de> Cc: stable@vger.kernel.org # 3.17+ Signed-off-by:
-
Calum Mackay authored
Commit 530ea421 ("nfs: Referrals should use the same proto setting as their parent") encloses the fix with #ifdef CONFIG_SUNRPC_XPRT_RDMA. CONFIG_SUNRPC_XPRT_RDMA is a tristate option, so it should be tested with #if IS_ENABLED(). Fixes: 530ea421 ("nfs: Referrals should use the same proto setting as their parent") Reported-by:
Calum Mackay <calum.mackay@oracle.com> Signed-off-by:
-
Jeff Layton authored
When reclaiming a delegation via CLAIM_PREVIOUS open, the server can indicate that the delegation has been recalled since it was issued by setting the "recalled" flag in the delegation. Ensure that we respect the flag by initiating a delegation return when it is set. Signed-off-by:
Jeff Layton <jlayton@kernel.org> Signed-off-by:
-
Souptick Joarder authored
Use new return type vm_fault_t for fault handler in struct vm_operations_struct. For now, this is just documenting that the function returns a VM_FAULT value rather than an errno. Once all instances are converted, vm_fault_t will become a distinct type. see commit 1c8f4220 ("mm: change return type to vm_fault_t") for reference. Signed-off-by:
Souptick Joarder <jrdr.linux@gmail.com> Reviewed-by:
Matthew Wilcox <mawilcox@microsoft.com> Signed-off-by:
-
Chengguang Xu authored
Even though the caller of nfs_idmap_prepare_message() checks return code in their side but it's better to add an error check for match_int() so that we can avoid unnecessary operations when bad int arg is detected. Signed-off-by:
Chengguang Xu <cgxu519@gmx.com> Signed-off-by:
-
- 26 Jul, 2018 4 commits
-
-
Lance Shelton authored
Return -ESTALE to force a lookup when the file has no more links Signed-off-by:
Lance Shelton <lance.shelton@hammerspace.com> Signed-off-by:
-
Trond Myklebust authored
execute_ok() will only check the mode bits if the object is not a directory, so we don't need to revalidate the attributes in that case. Signed-off-by: -
Trond Myklebust authored
When nfs_update_inode() sets NFS_INO_INVALID_ACCESS it is a sign that we want to revalidate the access cache, not the inode attributes. In fact we only want to revalidate here if we see that the mode bits are invalid, so check for NFS_INO_INVALID_OTHER instead. Reported-by:
Olga Kornievskaia <aglo@umich.edu> Signed-off-by:
-
Trond Myklebust authored
If the writes are being rescheduled due to a pNFS error, then we really want to immediately start a new flush. The O_DIRECT code already does this, so we only need to worry about buffered writes. Signed-off-by:
-
