summaryrefslogtreecommitdiffstats
path: root/README
diff options
context:
space:
mode:
authorJeff Layton <jlayton@kernel.org>2023-03-03 07:16:00 -0500
committerChuck Lever <chuck.lever@oracle.com>2023-04-26 09:05:00 -0400
commit2005f5b9c35bd736c81e9f24f5c5051967c022ee (patch)
treea0a31fc7468a50beccecf925af17c5fa676578e5 /README
parentf0aa4852e63f9c1cfd4322c770e69d7e6817e906 (diff)
downloadlinux-stable-2005f5b9c35bd736c81e9f24f5c5051967c022ee.tar.gz
linux-stable-2005f5b9c35bd736c81e9f24f5c5051967c022ee.tar.bz2
linux-stable-2005f5b9c35bd736c81e9f24f5c5051967c022ee.zip
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>
Diffstat (limited to 'README')
0 files changed, 0 insertions, 0 deletions