kernel/linux.git/fs/dlm/plock.c, branch v6.12.80

dlm: adapt to breakup of struct file_lock

2024-02-05T12:11:42+00:00

Most of the existing APIs have remained the same, but subsystems that access file_lock fields directly need to reach into struct file_lock_core now. Signed-off-by: Jeff Layton Link: https://lore.kernel.org/r/20240131-flsplit-v3-37-c6129007ee8d@kernel.org Reviewed-by: NeilBrown Signed-off-by: Christian Brauner

filelock: split common fields into struct file_lock_core

2024-02-05T12:11:38+00:00

In a future patch, we're going to split file leases into their own structure. Since a lot of the underlying machinery uses the same fields move those into a new file_lock_core, and embed that inside struct file_lock. For now, add some macros to ensure that we can continue to build while the conversion is in progress. Signed-off-by: Jeff Layton Link: https://lore.kernel.org/r/20240131-flsplit-v3-17-c6129007ee8d@kernel.org Reviewed-by: NeilBrown Signed-off-by: Christian Brauner

dlm: convert to using new filelock helpers

2024-02-05T12:11:36+00:00

Convert to using the new file locking helper functions. Also, in later patches we're going to introduce some temporary macros with names that clash with the variable name in dlm_posix_unlock. Rename it. Signed-off-by: Jeff Layton Link: https://lore.kernel.org/r/20240131-flsplit-v3-8-c6129007ee8d@kernel.org Reviewed-by: NeilBrown Signed-off-by: Christian Brauner

dlm: use FL_SLEEP to determine blocking vs non-blocking

2023-11-16T17:59:19+00:00

This patch uses the FL_SLEEP flag in struct file_lock to determine if the lock request is a blocking or non-blocking request. Before dlm was using IS_SETLKW() was being used which is not usable for lock requests coming from lockd when EXPORT_OP_SAFE_ASYNC_LOCK inside the export flags is set. Signed-off-by: Alexander Aring Signed-off-by: David Teigland

dlm: use fl_owner from lockd

2023-11-16T17:59:19+00:00

This patch is changing the fl_owner value in case of an nfs lock request to not be the pid of lockd. Instead this patch changes it to be the owner value that nfs is giving us. Currently there exists proved problems with this behaviour. One nfsd server was created to export a gfs2 filesystem mount. Two nfs clients doing a nfs mount of this export. Those two clients should conflict each other operating on the same nfs file. A small test program was written: int main(int argc, const char *argv[]) { struct flock fl = { .l_type = F_WRLCK, .l_whence = SEEK_SET, .l_start = 1L, .l_len = 1L, }; int fd; fd = open("filename", O_RDWR | O_CREAT, 0700); printf("try to lock...\n"); fcntl(fd, F_SETLKW, &fl); printf("locked!\n"); getc(stdin); return 0; } Running on both clients at the same time and don't interrupting by pressing any key. It will show that both clients are able to acquire the lock which shouldn't be the case. The issue is here that the fl_owner value is the same and the lock context of both clients should be separated. This patch lets lockd define how to deal with lock contexts and chose hopefully the right fl_owner value. A test after this patch was made and the locks conflicts each other which should be the case. Acked-by: Jeff Layton Signed-off-by: Alexander Aring Signed-off-by: David Teigland

dlm: fix plock lookup when using multiple lockspaces

2023-08-25T15:31:39+00:00

All posix lock ops, for all lockspaces (gfs2 file systems) are sent to userspace (dlm_controld) through a single misc device. The dlm_controld daemon reads the ops from the misc device and sends them to other cluster nodes using separate, per-lockspace cluster api communication channels. The ops for a single lockspace are ordered at this level, so that the results are received in the same sequence that the requests were sent. When the results are sent back to the kernel via the misc device, they are again funneled through the single misc device for all lockspaces. When the dlm code in the kernel processes the results from the misc device, these results will be returned in the same sequence that the requests were sent, on a per-lockspace basis. A recent change in this request/reply matching code missed the "per-lockspace" check (fsid comparison) when matching request and reply, so replies could be incorrectly matched to requests from other lockspaces. Cc: stable@vger.kernel.org Reported-by: Barry Marson Fixes: 57e2c2f2d94c ("fs: dlm: fix mismatch of plock results from userspace") Signed-off-by: Alexander Aring Signed-off-by: David Teigland

fs: dlm: add plock dev tracepoints

2023-08-10T15:33:03+00:00

I currently debug nfs plock handling and introduce those two tracepoints for getting more information about what is happening there if the user space reads plock operations from kernel and writing the result back. Signed-off-by: Alexander Aring Signed-off-by: David Teigland

fs: dlm: check on plock ops when exit dlm

2023-08-10T15:33:03+00:00

To be sure we don't have any issues that there are leftover plock ops in either send_list or recv_list we simple check if either one of the list are empty when we exit the dlm subsystem. Signed-off-by: Alexander Aring Signed-off-by: David Teigland

fs: dlm: add missing spin_unlock

2023-08-10T15:33:03+00:00

This patch fixes commit dc52cd2eff4a ("fs: dlm: fix F_CANCELLK to cancel pending request") that we don't unlock the ops_lock in a rate case when a waiter cannot be found. This case can only happen when cancellation of plock operation was successful but no kernel waiter was being found. Fixes: dc52cd2eff4a ("fs: dlm: fix F_CANCELLK to cancel pending request") Signed-off-by: Alexander Aring Signed-off-by: David Teigland

fs: dlm: fix F_CANCELLK to cancel pending request

2023-07-20T22:25:04+00:00

This patch fixes the current handling of F_CANCELLK by not just doing a unlock as we need to try to cancel a lock at first. A unlock makes sense on a non-blocking lock request but if it's a blocking lock request we need to cancel the request until it's not granted yet. This patch is fixing this behaviour by first try to cancel a lock request and if it's failed it's unlocking the lock which seems to be granted. Note: currently the nfs locking handling was disabled by commit 40595cdc93ed ("nfs: block notification on fs with its own ->lock"). However DLM was never being updated regarding to this change. Future patches will try to fix lockd lock requests for DLM. This patch is currently assuming the upstream DLM lockd handling is correct. Signed-off-by: Alexander Aring Signed-off-by: David Teigland