diff options
author | Jeff Layton <jlayton@kernel.org> | 2023-03-03 07:16:00 -0500 |
---|---|---|
committer | Chuck Lever <chuck.lever@oracle.com> | 2023-04-26 09:05:00 -0400 |
commit | 2005f5b9c35bd736c81e9f24f5c5051967c022ee (patch) | |
tree | a0a31fc7468a50beccecf925af17c5fa676578e5 /security/bpf/Makefile | |
parent | f0aa4852e63f9c1cfd4322c770e69d7e6817e906 (diff) | |
download | linux-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 'security/bpf/Makefile')
0 files changed, 0 insertions, 0 deletions