lockd: fix races in client GRANTED_MSG wait logic
authorJeff Layton <jlayton@kernel.org>
Fri, 3 Mar 2023 12:16:00 +0000 (07:16 -0500)
committerChuck Lever <chuck.lever@oracle.com>
Wed, 26 Apr 2023 13:05:00 +0000 (09:05 -0400)
commit2005f5b9c35bd736c81e9f24f5c5051967c022ee
treea0a31fc7468a50beccecf925af17c5fa676578e5
parentf0aa4852e63f9c1cfd4322c770e69d7e6817e906
lockd: fix races in client GRANTED_MSG wait logic

After the wait for a grant is done (for whatever reason), nlmclnt_block
updates the status of the nlm_rqst with the status of the block. At the
point it does this, however, the block is still queued its status could
change at any time.

This is particularly a problem when the waiting task is signaled during
the wait. We can end up giving up on the lock just before the GRANTED_MSG
callback comes in, and accept it even though the lock request gets back
an error, leaving a dangling lock on the server.

Since the nlm_wait never lives beyond the end of nlmclnt_lock, put it on
the stack and add functions to allow us to enqueue and dequeue the
block. Enqueue it just before the lock/wait loop, and dequeue it
just after we exit the loop instead of waiting until the end of
the function. Also, scrape the status at the time that we dequeue it to
ensure that it's final.

Reported-by: Yongcheng Yang <yoyang@redhat.com>
Link: https://bugzilla.redhat.com/show_bug.cgi?id=2063818
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
fs/lockd/clntlock.c
fs/lockd/clntproc.c
include/linux/lockd/lockd.h