summaryrefslogtreecommitdiff
path: root/fs
AgeCommit message (Collapse)AuthorFilesLines
2021-05-20NFSv4: Fix a NULL pointer dereference in pnfs_mark_matching_lsegs_return()Anna Schumaker1-8/+7
Commit de144ff4234f changes _pnfs_return_layout() to call pnfs_mark_matching_lsegs_return() passing NULL as the struct pnfs_layout_range argument. Unfortunately, pnfs_mark_matching_lsegs_return() doesn't check if we have a value here before dereferencing it, causing an oops. I'm able to hit this crash consistently when running connectathon basic tests on NFS v4.1/v4.2 against Ontap. Fixes: de144ff4234f ("NFSv4: Don't discard segments marked for return in _pnfs_return_layout()") Cc: stable@vger.kernel.org Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com> Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
2021-05-20pNFS/NFSv4: Remove redundant initialization of 'rd_size'Yang Li1-1/+1
Variable 'rd_size' is being initialized however this value is never read as 'rd_size' is assigned a new value in for statement. Remove the redundant assignment. Clean up clang warning: fs/nfs/pnfs.c:2681:6: warning: Value stored to 'rd_size' during its initialization is never read [clang-analyzer-deadcode.DeadStores] Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Yang Li <yang.lee@linux.alibaba.com> Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
2021-05-20NFS: fix an incorrect limit in filelayout_decode_layout()Dan Carpenter1-1/+1
The "sizeof(struct nfs_fh)" is two bytes too large and could lead to memory corruption. It should be NFS_MAXFHSIZE because that's the size of the ->data[] buffer. I reversed the size of the arguments to put the variable on the left. Fixes: 16b374ca439f ("NFSv4.1: pnfs: filelayout: add driver's LAYOUTGET and GETDEVICEINFO infrastructure") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
2021-05-20fs/nfs: Use fatal_signal_pending instead of signal_pendingzhouchuangao1-2/+2
We set the state of the current process to TASK_KILLABLE via prepare_to_wait(). Should we use fatal_signal_pending() to detect the signal here? Fixes: b4868b44c562 ("NFSv4: Wait for stateid updates after CLOSE/OPEN_DOWNGRADE") Signed-off-by: zhouchuangao <zhouchuangao@vivo.com> Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
2021-05-20xfs: restore old ioctl definitionsDarrick J. Wong1-0/+4
These ioctl definitions in xfs_fs.h are part of the userspace ABI and were mistakenly removed during the 5.13 merge window. Fixes: 9fefd5db08ce ("xfs: convert to fileattr") Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Brian Foster <bfoster@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de>
2021-05-20xfs: fix deadlock retry tracepoint argumentsDarrick J. Wong1-1/+3
sc->ip is the inode that's being scrubbed, which means that it's not set for scrub types that don't involve inodes. If one of those scrubbers (e.g. inode btrees) returns EDEADLOCK, we'll trip over the null pointer. Fix that by reporting either the file being examined or the file that was used to call scrub. Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Brian Foster <bfoster@redhat.com>
2021-05-20xfs: retry allocations when locality-based search failsDarrick J. Wong1-1/+14
If a realtime allocation fails because we can't find a sufficiently large free extent satisfying locality rules, relax the locality rules and try again. This reduces the occurrence of short writes to realtime files when the write size is large and the free space is fragmented. This was originally discovered by running generic/186 with the realtime reflink patchset and a 128k cow extent size hint, but the short write symptoms can manifest with a 128k extent size hint and no reflink, so apply the fix now. Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Allison Henderson <allison.henderson@oracle.com>
2021-05-20block: fix a race between del_gendisk and BLKRRPARTGulam Mohamed1-0/+3
When BLKRRPART is called concurrently with del_gendisk, the partitions rescan can create a stale partition that will never be be cleaned up. Fix this by checking the the disk is up before rescanning partitions while under bd_mutex. Signed-off-by: Gulam Mohamed <gulam.mohamed@oracle.com> [hch: split from a larger patch] Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Ming Lei <ming.lei@redhat.com> Link: https://lore.kernel.org/r/20210514131842.1600568-3-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-05-20block: prevent block device lookups at the beginning of del_gendiskChristoph Hellwig1-10/+5
As an artifact of how gendisk lookup used to work in earlier kernels, GENHD_FL_UP is only cleared very late in del_gendisk, and a global lock is used to prevent opens from succeeding while del_gendisk is tearing down the gendisk. Switch to clearing the flag early and under bd_mutex so that callers can use bd_mutex to stabilize the flag, which removes the need for the global mutex. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Ming Lei <ming.lei@redhat.com> Link: https://lore.kernel.org/r/20210514131842.1600568-2-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-05-20btrfs: zoned: fix parallel compressed writesJohannes Thumshirn1-4/+38
When multiple processes write data to the same block group on a compressed zoned filesystem, the underlying device could report I/O errors and data corruption is possible. This happens because on a zoned file system, compressed data writes where sent to the device via a REQ_OP_WRITE instead of a REQ_OP_ZONE_APPEND operation. But with REQ_OP_WRITE and parallel submission it cannot be guaranteed that the data is always submitted aligned to the underlying zone's write pointer. The change to using REQ_OP_ZONE_APPEND instead of REQ_OP_WRITE on a zoned filesystem is non intrusive on a regular file system or when submitting to a conventional zone on a zoned filesystem, as it is guarded by btrfs_use_zone_append. Reported-by: David Sterba <dsterba@suse.com> Fixes: 9d294a685fbc ("btrfs: zoned: enable to mount ZONED incompat flag") CC: stable@vger.kernel.org # 5.12.x: e380adfc213a13: btrfs: zoned: pass start block to btrfs_use_zone_append CC: stable@vger.kernel.org # 5.12.x Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by: David Sterba <dsterba@suse.com>
2021-05-20btrfs: zoned: pass start block to btrfs_use_zone_appendJohannes Thumshirn4-7/+6
btrfs_use_zone_append only needs the passed in extent_map's block_start member, so there's no need to pass in the full extent map. This also enables the use of btrfs_use_zone_append in places where we only have a start byte but no extent_map. Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
2021-05-20io_uring: fortify tctx/io_wq cleanupPavel Begunkov1-4/+4
We don't want anyone poking into tctx->io_wq awhile it's being destroyed by io_wq_put_and_exit(), and even though it shouldn't even happen, if buggy would be preferable to get a NULL-deref instead of subtle delayed failure or UAF. Signed-off-by: Pavel Begunkov <asml.silence@gmail.com> Link: https://lore.kernel.org/r/827b021de17926fd807610b3e53a5a5fa8530856.1621513214.git.asml.silence@gmail.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-05-20gfs2: Clean up revokes on normal withdrawsBob Peterson5-4/+12
Before this patch, the system ail lists were cleaned up if the logd process withdrew, but on other withdraws, they were not cleaned up. This included the cleaning up of the revokes as well. This patch reorganizes things a bit so that all withdraws (not just logd) clean up the ail lists, including any pending revokes. Signed-off-by: Bob Peterson <rpeterso@redhat.com> Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
2021-05-20gfs2: fix a deadlock on withdraw-during-mountBob Peterson1-3/+21
Before this patch, gfs2 would deadlock because of the following sequence during mount: mount gfs2_fill_super gfs2_make_fs_rw <--- Detects IO error with glock kthread_stop(sdp->sd_quotad_process); <--- Blocked waiting for quotad to finish logd Detects IO error and the need to withdraw calls gfs2_withdraw gfs2_make_fs_ro kthread_stop(sdp->sd_quotad_process); <--- Blocked waiting for quotad to finish gfs2_quotad gfs2_statfs_sync gfs2_glock_wait <---- Blocked waiting for statfs glock to be granted glock_work_func do_xmote <---Detects IO error, can't release glock: blocked on withdraw glops->go_inval glock_blocked_by_withdraw requeue glock work & exit <--- work requeued, blocked by withdraw This patch makes a special exception for the statfs system inode glock, which allows the statfs glock UNLOCK to proceed normally. That allows the quotad daemon to exit during the withdraw, which allows the logd daemon to exit during the withdraw, which allows the mount to exit. Signed-off-by: Bob Peterson <rpeterso@redhat.com> Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
2021-05-20gfs2: fix scheduling while atomic bug in glocksBob Peterson1-0/+2
Before this patch, in the unlikely event that gfs2_glock_dq encountered a withdraw, it would do a wait_on_bit to wait for its journal to be recovered, but it never released the glock's spin_lock, which caused a scheduling-while-atomic error. This patch unlocks the lockref spin_lock before waiting for recovery. Fixes: 601ef0d52e96 ("gfs2: Force withdraw to replay journals and wait for it to finish") Cc: stable@vger.kernel.org # v5.7+ Reported-by: Alexander Aring <aahringo@redhat.com> Signed-off-by: Bob Peterson <rpeterso@redhat.com> Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
2021-05-20gfs2: Fix I_NEW check in gfs2_dinode_inBob Peterson1-1/+1
Patch 4a378d8a0d96 added a new check for I_NEW inodes, but unfortunately it used the wrong variable, i_flags. This caused GFS2 to withdraw when gfs2_lookup_by_inum needed to refresh an I_NEW inode. This patch switches to use the correct variable, i_state. Fixes: 4a378d8a0d96 ("gfs2: be careful with inode refresh") Signed-off-by: Bob Peterson <rpeterso@redhat.com> Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
2021-05-20gfs2: Prevent direct-I/O write fallback errors from getting lostAndreas Gruenbacher1-1/+4
When a direct I/O write falls entirely and falls back to buffered I/O and the buffered I/O fails, the write failed with return value 0 instead of the error number reported by the buffered I/O. Fix that. Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
2021-05-20udf: Fix NULL pointer dereference in udf_symlink functionArturo Giusti1-0/+4
In function udf_symlink, epos.bh is assigned with the value returned by udf_tgetblk. The function udf_tgetblk is defined in udf/misc.c and returns the value of sb_getblk function that could be NULL. Then, epos.bh is used without any check, causing a possible NULL pointer dereference when sb_getblk fails. This fix adds a check to validate the value of epos.bh. Link: https://bugzilla.kernel.org/show_bug.cgi?id=213083 Signed-off-by: Arturo Giusti <koredump@protonmail.com> Signed-off-by: Jan Kara <jack@suse.cz>
2021-05-20Defer close only when lease is enabled.Rohith Surabattula3-0/+4
When smb2 lease parameter is disabled on server. Server grants batch oplock instead of RHW lease by default on open, inode page cache needs to be zapped immediatley upon close as cache is not valid. Signed-off-by: Rohith Surabattula <rohiths@microsoft.com> Signed-off-by: Steve French <stfrench@microsoft.com>
2021-05-20Fix kernel oops when CONFIG_DEBUG_ATOMIC_SLEEP is enabled.Rohith Surabattula4-18/+23
Removed oplock_break_received flag which was added to achieve synchronization between oplock handler and open handler by earlier commit. It is not needed because there is an existing lock open_file_lock to achieve the same. find_readable_file takes open_file_lock and then traverses the openFileList. Similarly, cifs_oplock_break while closing the deferred handle (i.e cifsFileInfo_put) takes open_file_lock and then sends close to the server. Added comments for better readability. Signed-off-by: Rohith Surabattula <rohiths@microsoft.com> Signed-off-by: Steve French <stfrench@microsoft.com>
2021-05-20cifs: Fix inconsistent indentingJiapeng Chong1-1/+1
Eliminate the follow smatch warning: fs/cifs/fs_context.c:1148 smb3_fs_context_parse_param() warn: inconsistent indenting. Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Signed-off-by: Steve French <stfrench@microsoft.com>
2021-05-20cifs: fix memory leak in smb2_copychunk_rangeRonnie Sahlberg1-0/+2
When using smb2_copychunk_range() for large ranges we will run through several iterations of a loop calling SMB2_ioctl() but never actually free the returned buffer except for the final iteration. This leads to memory leaks everytime a large copychunk is requested. Fixes: 9bf0c9cd4314 ("CIFS: Fix SMB2/SMB3 Copy offload support (refcopy) for large files") Cc: <stable@vger.kernel.org> Reviewed-by: Aurelien Aptel <aaptel@suse.com> Signed-off-by: Ronnie Sahlberg <lsahlber@redhat.com> Signed-off-by: Steve French <stfrench@microsoft.com>
2021-05-19Merge tag 'fs.idmapped.mount_setattr.v5.13-rc3' of ↵Linus Torvalds1-1/+5
gitolite.kernel.org:pub/scm/linux/kernel/git/brauner/linux Pull mount_setattr fix from Christian Brauner: "This makes an underlying idmapping assumption more explicit. We currently don't have any filesystems that support idmapped mounts which are mountable inside a user namespace, i.e. where s_user_ns != init_user_ns. That was a deliberate decision for now as userns root can just mount the filesystem themselves. Express this restriction explicitly and enforce it until there's a real use-case for this. This way we can notice it and will have a chance to adapt and audit our translation helpers and fstests appropriately if we need to support such filesystems" * tag 'fs.idmapped.mount_setattr.v5.13-rc3' of gitolite.kernel.org:pub/scm/linux/kernel/git/brauner/linux: fs/mount_setattr: tighten permission checks
2021-05-19SMB3: incorrect file id in requests compounded with openSteve French1-3/+3
See MS-SMB2 3.2.4.1.4, file ids in compounded requests should be set to 0xFFFFFFFFFFFFFFFF (we were treating it as u32 not u64 and setting it incorrectly). Signed-off-by: Steve French <stfrench@microsoft.com> Reported-by: Stefan Metzmacher <metze@samba.org> Reviewed-by: Shyam Prasad N <sprasad@microsoft.com>
2021-05-19getcwd(2): clean up error handlingAl Viro1-17/+12
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2021-05-19d_path: prepend_path() is unlikely to return non-zeroAl Viro1-3/+3
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2021-05-19d_path: prepend_path(): lift the inner loop into a new helperAl Viro1-39/+38
... and leave the rename_lock/mount_lock handling in prepend_path() itself Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2021-05-19d_path: prepend_path(): lift resetting b in case when we'd return 3 out of loopAl Viro1-1/+3
preparation to extracting the loop into helper (next commit) Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2021-05-19d_path: prepend_path(): get rid of vfsmntAl Viro1-7/+4
it's kept equal to &mnt->mnt all along. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2021-05-19d_path: introduce struct prepend_bufferAl Viro1-67/+75
We've a lot of places where we have pairs of form (pointer to end of buffer, amount of space left in front of that). These sit in pairs of variables located next to each other and usually passed by reference. Turn those into instances of new type (struct prepend_buffer) and pass reference to the pair instead of pairs of references to its fields. Declared and initialized by DECLARE_BUFFER(name, buf, buflen). extract_string(prepend_buffer) returns the buffer contents if no overflow has happened, ERR_PTR(ENAMETOOLONG) otherwise. All places where we used to have that boilerplate converted to use of that helper. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2021-05-19d_path: make prepend_name() booleanAl Viro1-6/+6
It returns only 0 or -ENAMETOOLONG and both callers only check if the result is negative. Might as well return true on success and false on failure... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2021-05-19d_path: lift -ENAMETOOLONG handling into callers of prepend_path()Al Viro1-28/+11
The only negative value ever returned by prepend_path() is -ENAMETOOLONG and callers can recognize that situation (overflow) by looking at the sign of buflen. Lift that into the callers; we already have the same logics (buf if buflen is non-negative, ERR_PTR(-ENAMETOOLONG) otherwise) in several places and that'll become a new primitive several commits down the road. Make prepend_path() return 0 instead of -ENAMETOOLONG. That makes for saner calling conventions (0/1/2/3/-ENAMETOOLONG is obnoxious) and callers actually get simpler, especially once the aforementioned primitive gets added. In prepend_path() itself we switch prepending the / (in case of empty path) to use of prepend() - no need to open-code that, compiler will do the right thing. It's exactly the same logics as in __dentry_path(). Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2021-05-19d_path: don't bother with return value of prepend()Al Viro1-11/+9
Only simple_dname() checks it, and there we can simply do those calls and check for overflow (by looking of negative buflen) in the end. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2021-05-19getcwd(2): saner logics around prepend_path() callAl Viro1-13/+4
The only negative value that might get returned by prepend_path() is -ENAMETOOLONG, and that happens only on overflow. The same goes for prepend_unreachable(). Overflow is detectable by observing negative buflen, so we can simplify the control flow around the prepend_path() call. Expand prepend_unreachable(), while we are at it - that's the only caller. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2021-05-19d_path: get rid of path_with_deleted()Al Viro1-18/+5
expand in the sole caller; transform the initial prepends similar to what we'd done in dentry_path() (prepend_path() will fail the right way if we call it with negative buflen, same as __dentry_path() does). Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2021-05-19d_path: regularize handling of root dentry in __dentry_path()Al Viro1-16/+5
All path-forming primitives boil down to sequence of prepend_name() on dentries encountered along the way toward root. Each time we prepend / + dentry name to the buffer. Normally that does exactly what we want, but there's a corner case when we don't call prepend_name() at all (in case of __dentry_path() that happens if we are given root dentry). We obviously want to end up with "/", rather than "", so this corner case needs to be handled. __dentry_path() used to manually put '/' in the end of buffer before doing anything else, to be overwritten by the first call of prepend_name() if one happens and to be left in place if we don't call prepend_name() at all. That required manually checking that we had space in the buffer (prepend_name() and prepend() take care of such checks themselves) and lead to clumsy keeping track of return value. A better approach is to check if the main loop has added anything into the buffer and prepend "/" if it hasn't. A side benefit of using prepend() is that it does the right thing if we'd already run out of buffer, making the overflow-handling logics simpler. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2021-05-19signalfd: Remove SIL_PERF_EVENT fields from signalfd_siginfoEric W. Biederman1-10/+6
With the addition of ssi_perf_data and ssi_perf_type struct signalfd_siginfo is dangerously close to running out of space. All that remains is just enough space for two additional 64bit fields. A practice of adding all possible siginfo_t fields into struct singalfd_siginfo can not be supported as adding the missing fields ssi_lower, ssi_upper, and ssi_pkey would require two 64bit fields and one 32bit fields. In practice the fields ssi_perf_data and ssi_perf_type can never be used by signalfd as the signal that generates them always delivers them synchronously to the thread that triggers them. Therefore until someone actually needs the fields ssi_perf_data and ssi_perf_type in signalfd_siginfo remove them. This leaves a bit more room for future expansion. v1: https://lkml.kernel.org/r/20210503203814.25487-12-ebiederm@xmission.com v2: https://lkml.kernel.org/r/20210505141101.11519-12-ebiederm@xmission.com Link: https://lkml.kernel.org/r/20210517195748.8880-5-ebiederm@xmission.com Reviewed-by: Marco Elver <elver@google.com> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
2021-05-19signal: Deliver all of the siginfo perf data in _perfEric W. Biederman1-1/+2
Don't abuse si_errno and deliver all of the perf data in _perf member of siginfo_t. Note: The data field in the perf data structures in a u64 to allow a pointer to be encoded without needed to implement a 32bit and 64bit version of the same structure. There already exists a 32bit and 64bit versions siginfo_t, and the 32bit version can not include a 64bit member as it only has 32bit alignment. So unsigned long is used in siginfo_t instead of a u64 as unsigned long can encode a pointer on all architectures linux supports. v1: https://lkml.kernel.org/r/m11rarqqx2.fsf_-_@fess.ebiederm.org v2: https://lkml.kernel.org/r/20210503203814.25487-10-ebiederm@xmission.com v3: https://lkml.kernel.org/r/20210505141101.11519-11-ebiederm@xmission.com Link: https://lkml.kernel.org/r/20210517195748.8880-4-ebiederm@xmission.com Reviewed-by: Marco Elver <elver@google.com> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
2021-05-19signal: Implement SIL_FAULT_TRAPNOEric W. Biederman1-5/+3
Now that si_trapno is part of the union in _si_fault and available on all architectures, add SIL_FAULT_TRAPNO and update siginfo_layout to return SIL_FAULT_TRAPNO when the code assumes si_trapno is valid. There is room for future changes to reduce when si_trapno is valid but this is all that is needed to make si_trapno and the other members of the the union in _sigfault mutually exclusive. Update the code that uses siginfo_layout to deal with SIL_FAULT_TRAPNO and have the same code ignore si_trapno in in all other cases. v1: https://lkml.kernel.org/r/m1o8dvs7s7.fsf_-_@fess.ebiederm.org v2: https://lkml.kernel.org/r/20210505141101.11519-6-ebiederm@xmission.com Link: https://lkml.kernel.org/r/20210517195748.8880-2-ebiederm@xmission.com Reviewed-by: Marco Elver <elver@google.com> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
2021-05-18NFSD: Update nfsd_cb_args tracepointChuck Lever1-3/+3
Clean-up: Re-order the display of IP address and client ID to be consistent with other _cb_ tracepoints. Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
2021-05-18NFSD: Remove the nfsd_cb_work and nfsd_cb_done tracepointsChuck Lever2-53/+0
Clean up: These are noise in properly working systems. If you really need to observe the operation of the callback mechanism, use the sunrpc:rpc\* tracepoints along with the workqueue tracepoints. Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
2021-05-18NFSD: Add an nfsd_cb_probe tracepointChuck Lever2-0/+2
Record a tracepoint event when the server performs a callback probe. This event can be enabled as a group with other nfsd_cb tracepoints. Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
2021-05-18NFSD: Replace the nfsd_deleg_break tracepointChuck Lever2-2/+32
Renamed so it can be enabled as a set with the other nfsd_cb_ tracepoints. And, consistent with those tracepoints, report the address of the client, the client ID the server has given it, and the state ID being recalled. Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
2021-05-18NFSD: Add an nfsd_cb_offload tracepointChuck Lever2-0/+38
Record the arguments of CB_OFFLOAD callbacks so we can better observe asynchronous copy-offload behavior. For example: nfsd-995 [008] 7721.934222: nfsd_cb_offload: addr=192.168.2.51:0 client 6092a47c:35a43fc1 fh_hash=0x8739113a count=116528 status=0 Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Cc: Olga Kornievskaia <kolga@netapp.com> Cc: Dai Ngo <Dai.Ngo@oracle.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
2021-05-18NFSD: Add an nfsd_cb_lm_notify tracepointChuck Lever2-1/+29
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>
2021-05-18NFSD: Enhance the nfsd_cb_setup tracepointChuck Lever2-2/+28
Display the transport protocol and authentication flavor so admins can see what they might be getting wrong. Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
2021-05-18NFSD: Remove spurious cb_setup_err tracepointChuck Lever1-3/+1
This path is not really an error path, so the tracepoint I added there is just noise. Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
2021-05-18NFSD: Adjust cb_shutdown tracepointChuck Lever1-1/+3
Show when the upper layer requested a shutdown. RPC tracepoints can already show when rpc_shutdown_client() is called. Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
2021-05-18NFSD: Add cb_lost tracepointChuck Lever2-0/+3
Provide more clarity about when the callback channel is in trouble. Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
2021-05-18NFSD: Drop TRACE_DEFINE_ENUM for NFSD4_CB_<state> macrosChuck Lever1-5/+0
TRACE_DEFINE_ENUM() is necessary for enum {} but not for C macros. Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com>