An error occurred fetching the project authors.
- 18 May, 2021 11 commits
-
-
Chuck Lever authored
When the server kicks off a CB_LM_NOTIFY callback, record its arguments so we can better observe asynchronous locking behavior. For example: nfsd-998 [002] 1471.705873: nfsd_cb_notify_lock: addr=192.168.2.51:0 client 6092a47c:35a43fc1 fh_hash=0x8950b23a Signed-off-by:Chuck Lever <chuck.lever@oracle.com> Cc: Jeff Layton <jlayton@redhat.com> Signed-off-by:
J. Bruce Fields <bfields@redhat.com>
-
Chuck Lever authored
Provide more clarity about when the callback channel is in trouble. Signed-off-by:
-
Chuck Lever authored
Some of the most common cases are traced. Enough infrastructure is now in place that more can be added later, as needed. Signed-off-by:
-
Chuck Lever authored
Signed-off-by:
-
Chuck Lever authored
Improve observation of NFSv4 lease expiry. Signed-off-by:
-
Chuck Lever authored
Record client-requested termination of client IDs. Signed-off-by:
-
Chuck Lever authored
Signed-off-by:
-
Chuck Lever authored
This replaces a dprintk call site in order to get greater visibility on when client IDs are confirmed or re-used. Simple example: nfsd-995 [000] 126.622975: nfsd_compound: xid=0x3a34e2b1 opcnt=1 nfsd-995 [000] 126.623005: nfsd_cb_args: addr=192.168.2.51:45901 client 60958e3b:9213ef0e prog=1073741824 ident=1 nfsd-995 [000] 126.623007: nfsd_compound_status: op=1/1 OP_SETCLIENTID status=0 nfsd-996 [001] 126.623142: nfsd_compound: xid=0x3b34e2b1 opcnt=1 >>>> nfsd-996 [001] 126.623146: nfsd_clid_confirmed: client 60958e3b:9213ef0e nfsd-996 [001] 126.623148: nfsd_cb_probe: addr=192.168.2.51:45901 client 60958e3b:9213ef0e state=UNKNOWN nfsd-996 [001] 126.623154: nfsd_compound_status: op=1/1 OP_SETCLIENTID_CONFIRM status=0 Signed-off-by: -
Chuck Lever authored
Record when a client presents a different boot verifier than the one we know about. Typically this is a sign the client has rebooted, but sometimes it signals a conflicting client ID, which the client's administrator will need to address. Signed-off-by:
-
Chuck Lever authored
Record when a client tries to establish a lease record but uses an unexpected credential. This is often a sign of a configuration problem. Signed-off-by:
-
Chuck Lever authored
Since commit 9a6944fe ("tracing: Add a verifier to check string pointers for trace events"), which was merged in v5.13-rc1, TP_printk() no longer tacitly supports the "%.*s" format specifier. These are low value tracepoints, so just remove them. Reported-by:
David Wysochanski <dwysocha@redhat.com> Fixes: dd5e3fbc ("NFSD: Add tracepoints to the NFSD state management code") Signed-off-by:
-
- 20 Apr, 2021 1 commit
-
-
Gustavo A. R. Silva authored
In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple warnings by explicitly adding a couple of break statements instead of just letting the code fall through to the next case. Link: https://github.com/KSPP/linux/issues/115Signed-off-by:
Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by:
-
- 19 Apr, 2021 4 commits
-
-
J. Bruce Fields authored
It's OK to grant a read delegation to a client that holds a write, as long as it's the only client holding the write. We originally tried to do this in commit 94415b06 ("nfsd4: a client's own opens needn't prevent delegations"), which had to be reverted in commit 6ee65a77 ("Revert "nfsd4: a client's own opens needn't prevent delegations""). Signed-off-by:
-
J. Bruce Fields authored
No change in behavior, I'm just moving some code around to avoid forward references in a following patch. (To do someday: figure out how to split up nfs4state.c. It's big and disorganized.) Signed-off-by:
-
J. Bruce Fields authored
It's unusual but possible for multiple filehandles to point to the same file. In that case, we may end up with multiple nfs4_files referencing the same inode. For delegation purposes it will turn out to be useful to flag those cases. Signed-off-by:
-
J. Bruce Fields authored
The nfs4_file structure is per-filehandle, not per-inode, because the spec requires open and other state to be per filehandle. But it will turn out to be convenient for nfs4_files associated with the same inode to be hashed to the same bucket, so let's hash on the inode instead of the filehandle. Filehandle aliasing is rare, so that shouldn't have much performance impact. (If you have a ton of exported filesystems, though, and all of them have a root with inode number 2, could that get you an overlong hash chain? Perhaps this (and the v4 open file cache) should be hashed on the inode pointer instead.) Signed-off-by:
-
- 16 Apr, 2021 1 commit
-
-
J. Bruce Fields authored
If nfsd already has an open file that it plans to use for IO from another, it may not need to do another vfs open, but it still may need to break any delegations in case the existing opens are for another client. Symptoms are that we may incorrectly fail to break a delegation on a write open from a different client, when the delegation-holding client already has a write open. Fixes: 28df3d15 ("nfsd: clients don't need to break their own delegations") Signed-off-by:
-
- 15 Apr, 2021 1 commit
-
-
Jiapeng Chong authored
Fix the following clang warning: fs/nfsd/nfs4state.c:6276:1: warning: unused function 'end_offset' [-Wunused-function]. Reported-by:
Abaci Robot <abaci@linux.alibaba.com> Signed-off-by:
Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Signed-off-by:
-
- 22 Mar, 2021 4 commits
-
-
NeilBrown authored
mountd can now monitor clients appearing and disappearing in /proc/fs/nfsd/clients, and will log these events, in liu of the logging of mount/unmount events for NFSv3. Currently it cannot distinguish between unconfirmed clients (which might be transient and totally uninteresting) and confirmed clients. So add a "status: " line which reports either "confirmed" or "unconfirmed", and use fsnotify to report that the info file has been modified. This requires a bit of infrastructure to keep the dentry for the "info" file. There is no need to take a counted reference as the dentry must remain around until the client is removed. Signed-off-by:
NeilBrown <neilb@suse.de> Signed-off-by:
-
Trond Myklebust authored
In order to ensure that knfsd threads don't linger once the nfsd pseudofs is unmounted (e.g. when the container is killed) we let nfsd_umount() shut down those threads and wait for them to exit. This also should ensure that we don't need to do a kernel mount of the pseudofs, since the thread lifetime is now limited by the lifetime of the filesystem. Signed-off-by:
Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by:
-
J. Bruce Fields authored
We do this same logic repeatedly, and it's easy to get the sense of the comparison wrong. Signed-off-by:
-
Chuck Lever authored
NFSD initializes an encode xdr_stream only after the RPC layer has already inserted the RPC Reply header. Thus it behaves differently than xdr_init_encode does, which assumes the passed-in xdr_buf is entirely devoid of content. nfs4proc.c has this server-side stream initialization helper, but it is visible only to the NFSv4 code. Move this helper to a place that can be accessed by NFSv2 and NFSv3 server XDR functions. Signed-off-by:
-
- 09 Mar, 2021 2 commits
-
-
J. Bruce Fields authored
This reverts commit 94415b06. That commit claimed to allow a client to get a read delegation when it was the only writer. Actually it allowed a client to get a read delegation when *any* client has a write open! The main problem is that it's depending on nfs4_clnt_odstate structures that are actually only maintained for pnfs exports. This causes clients to miss writes performed by other clients, even when there have been intervening closes and opens, violating close-to-open cache consistency. We can do this a different way, but first we should just revert this. I've added pynfs 4.1 test DELEG19 to test for this, as I should have done originally! Cc: stable@vger.kernel.org Reported-by:
Timo Rothenpieler <timo@rothenpieler.org> Signed-off-by:
-
J. Bruce Fields authored
This reverts commit 50747dd5 "nfsd4: remove check_conflicting_opens warning", as a prerequisite for reverting 94415b06, which has a serious bug. Cc: stable@vger.kernel.org Signed-off-by:
-
- 06 Mar, 2021 1 commit
-
-
J. Bruce Fields authored
The typical result of the backwards comparison here is that the source server in a server-to-server copy will return BAD_STATEID within a few seconds of the copy starting, instead of giving the copy a full lease period, so the copy_file_range() call will end up unnecessarily returning a short read. Fixes: 624322f1 "NFSD add COPY_NOTIFY operation" Signed-off-by:
-
- 28 Jan, 2021 3 commits
-
-
J. Bruce Fields authored
I'm not sure why we're writing this out the hard way in so many places. Signed-off-by:
-
J. Bruce Fields authored
The set_client() was already taken care of by process_open1(). The comments here are mostly redundant with the code. Signed-off-by:
-
J. Bruce Fields authored
Every caller is setting this argument to false, so we don't need it. Also cut this comment a bit and remove an unnecessary warning. Signed-off-by:
-
- 25 Jan, 2021 6 commits
-
-
J. Bruce Fields authored
I think this unusual use of struct compound_state could cause confusion. It's not that much more complicated just to open-code this stateid lookup. The only change in behavior should be a different error return in the case the copy is using a source stateid that is a revoked delegation, but I doubt that matters. Signed-off-by:
-
J. Bruce Fields authored
This'll be useful elsewhere. Signed-off-by:
-
J. Bruce Fields authored
I think this is a better name, and I'm going to reuse elsewhere the code that does the lookup itself. Signed-off-by:
-
J. Bruce Fields authored
You can take the single-exit thing too far, I think. Signed-off-by:
-
J. Bruce Fields authored
Similarly, this STALE_CLIENTID check is already handled by: nfs4_preprocess_confirmed_seqid_op()-> nfs4_preprocess_seqid_op()-> nfsd4_lookup_stateid()-> set_client()-> STALE_CLIENTID() (This may cause it to return a different error in some cases where there are multiple things wrong; pynfs test SEQ10 regressed on this commit because of that, but I think that's the test's fault, and I've fixed it separately.) Signed-off-by: -
J. Bruce Fields authored
This STALE_CLIENTID check is redundant with the one in lookup_clientid(). There's a difference in behavior is in case of memory allocation failure, which I think isn't a big deal. Signed-off-by:
-
- 09 Dec, 2020 1 commit
-
-
Dai Ngo authored
Since commit b4868b44 ("NFSv4: Wait for stateid updates after CLOSE/OPEN_DOWNGRADE"), every inter server copy operation suffers 5 seconds delay regardless of the size of the copy. The delay is from nfs_set_open_stateid_locked when the check by nfs_stateid_is_sequential fails because the seqid in both nfs4_state and nfs4_stateid are 0. Fix by modifying nfs4_init_cp_state to return the stateid with seqid 1 instead of 0. This is also to conform with section 4.8 of RFC 7862. Here is the relevant paragraph from section 4.8 of RFC 7862: A copy offload stateid's seqid MUST NOT be zero. In the context of a copy offload operation, it is inappropriate to indicate "the most recent copy offload operation" using a stateid with a seqid of zero (see Section 8.2.2 of [RFC5661]). It is inappropriate because the stateid refers to internal state in the server and there may be several asynchronous COPY operations being performed in parallel on the same file by the server. Therefore, a copy offload stateid with a seqid of zero MUST be considered invalid. Fixes: ce0887ac ("NFSD add nfs4 inter ssc to nfsd4_copy") Signed-off-by:
Dai Ngo <dai.ngo@oracle.com> Signed-off-by:
-
- 30 Nov, 2020 1 commit
-
-
Chuck Lever authored
Refactor for clarity. Also, remove a stale comment. Commit ed941643 ("nfsd: implement machine credential support for some operations") added support for SP4_MACH_CRED, so state_protect_a is no longer completely ignored. Signed-off-by:
-
- 16 Oct, 2020 1 commit
-
-
Tom Rix authored
Because every path through nfs4_find_file()'s switch does an explicit return, the break is not needed. Signed-off-by:
Tom Rix <trix@redhat.com> Signed-off-by:
-
- 25 Sep, 2020 3 commits
-
-
J. Bruce Fields authored
Since only the v4 code cares about it, maybe it's better to leave rq_lease_breaker out of the common dispatch code? Signed-off-by: -
J. Bruce Fields authored
There are actually rare races where this is possible (e.g. if a new open intervenes between the read of i_writecount and the fi_fds). Signed-off-by: -
Hou Tao authored
Now when a read delegation is given, two delegation related traces will be printed: nfsd_deleg_open: client 5f45b854:e6058001 stateid 00000030:00000001 nfsd_deleg_none: client 5f45b854:e6058001 stateid 0000002f:00000001 Although the intention is to let developers know two stateid are returned, the traces are confusing about whether or not a read delegation is handled out. So renaming trace_nfsd_deleg_none() to trace_nfsd_open() and trace_nfsd_deleg_open() to trace_nfsd_deleg_read() to make the intension clearer. The patched traces will be: nfsd_deleg_read: client 5f48a967:b55b21cd stateid 00000003:00000001 nfsd_open: client 5f48a967:b55b21cd stateid 00000002:00000001 Suggested-by:Hou Tao <houtao1@huawei.com> Signed-off-by:
-
