- Sep 14, 2018
-
-
Trond Myklebust authored
Add a helper for the case when the nfs4 open state has been set to use a delegation stateid, and we want to revert to using the open stateid. Signed-off-by:
Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by:
Anna Schumaker <Anna.Schumaker@Netapp.com>
-
Trond Myklebust authored
The previous fix broke recovery of delegated stateids because it assumes that if we did not mark the delegation as suspect, then the delegation has effectively been revoked, and so it removes that delegation irrespectively of whether or not it is valid and still in use. While this is "mostly harmless" for ordinary I/O, we've seen pNFS fail with LAYOUTGET spinning in an infinite loop while complaining that we're using an invalid stateid (in this case the all-zero stateid). What we rather want to do here is ensure that the delegation is always correctly marked as needing testing when that is the case. So we want to close the loophole offered by nfs4_schedule_stateid_recovery(), which marks the state as needing to be reclaimed, but not the delegation that may be backing it. Fixes: 0e3d3e5d ("NFSv4.1 fix infinite loop on IO BAD_STATEID error") Signed-off-by:
-
Trond Myklebust authored
Now that the value of 'ino' can be NULL or an ERR_PTR(), we need to change the test in the tracepoint. Fixes: ce5624f7 ("NFSv4: Return NFS4ERR_DELAY when a layout fails...") Signed-off-by:
-
Trond Myklebust authored
If someone interrupts a wait on one or more outstanding layoutgets in pnfs_update_layout() then return the ERESTARTSYS/EINTR error. Signed-off-by:
-
Trond Myklebust authored
Now that the value of 'ino' can be NULL or an ERR_PTR(), we need to change the test in the tracepoint. Fixes: ce5624f7 ("NFSv4: Return NFS4ERR_DELAY when a layout fails...") Signed-off-by:
-
- Aug 21, 2018
-
-
Trond Myklebust authored
If we knew that the file was empty, we wouldn't be asking for a layout. Any optimisation here is already done before calling pnfs_update_layout(). As it stands, we sometimes end up doing an unnecessary inband read to the MDS even when holding a layout. Signed-off-by:
-
Trond Myklebust authored
If we get an error while retrieving the layout, then we should report it rather than falling back to I/O through the MDS. Signed-off-by:
Trond Myklebust <trond.myklebust@primarydata.com> Signed-off-by:
-
- Aug 16, 2018
-
-
Trond Myklebust authored
Yes, it is possible to get trapped in a loop, but the server should be administratively revoking the recalled layout if it never gets returned. Signed-off-by:
-
Trond Myklebust authored
When we update the layout stateid in nfs4_layoutreturn_refresh_stateid, we should also update the range in order to let the server know we're actually returning everything. Fixes: 16c278dbfa63 ("pnfs: Fix handling of NFS4ERR_OLD_STATEID replies...") Signed-off-by:
-
- Aug 15, 2018
-
-
Trond Myklebust authored
We must drop the lock before we can sleep in referring_call_exists(). Reported-by:
Jia-Ju Bai <baijiaju1990@gmail.com> Fixes: 045d2a6d ("NFSv4.1: Delay callback processing...") Cc: stable@vger.kernel.org # v4.9+ Signed-off-by:
-
Trond Myklebust authored
The use of the inode->i_lock was converted to a mutex, but we forgot to remove the old inode unlock/lock() pair that allowed the layout segment to be put inside the loop. Reported-by:
-
- Aug 13, 2018
-
-
Trond Myklebust authored
The back channel size is allowed to be 1 or greater. Signed-off-by:
-
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:
-
- Aug 09, 2018
-
-
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:
-
- Aug 08, 2018
-
-
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:
-
- Jul 31, 2018
-
-
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:
-
- Jul 30, 2018
-
-
Dave Wysochanski authored
Add a helper function to add the metrics in two rpc_iostats structures. Signed-off-by:
-
