summaryrefslogtreecommitdiffstats
path: root/security
diff options
context:
space:
mode:
authorAlexander Aring <aahringo@redhat.com>2022-04-04 16:06:45 -0400
committerDavid Teigland <teigland@redhat.com>2022-04-06 14:02:58 -0500
commit401597485cfc702ee75c4dc73345dcfcdb002d04 (patch)
treeca9a4c4ebce9bd2b589076ee5978b70112311531 /security
parente91ce03b27b6815cae064bb3d608b7cd26f3fab4 (diff)
downloadlinux-stable-401597485cfc702ee75c4dc73345dcfcdb002d04.tar.gz
linux-stable-401597485cfc702ee75c4dc73345dcfcdb002d04.tar.bz2
linux-stable-401597485cfc702ee75c4dc73345dcfcdb002d04.zip
dlm: cleanup lock handling in dlm_master_lookup
This patch will remove the following warning by sparse: fs/dlm/lock.c:1049:9: warning: context imbalance in 'dlm_master_lookup' - different lock contexts for basic block I tried to find any issues with the current handling and I did not find any. However it is hard to follow the lock handling in this area of dlm_master_lookup() and I suppose that sparse cannot realize that there are no issues. The variable "toss_list" makes it really hard to follow the lock handling because if it's set the rsb lock/refcount isn't held but the ls->ls_rsbtbl[b].lock is held and this is one reason why the rsb lock/refcount does not need to be held. If it's not set the ls->ls_rsbtbl[b].lock is not held but the rsb lock/refcount is held. The indicator of toss_list will be used to store the actual lock state. Another possibility is that a retry can happen and then it's hard to follow the specific code part. I did not find any issues but sparse cannot realize that there are no issues. To make it more easier to understand for developers and sparse as well, we remove the toss_list variable which indicates a specific lock state and move handling in between of this lock state in a separate function. This function can be called now in case when the initial lock states are taken which was previously signalled if toss_list was set or not. The advantage here is that we can release all locks/refcounts in mostly the same code block as it was taken. Afterwards sparse had no issues to figure out that there are no problems with the current lock behaviour. Signed-off-by: Alexander Aring <aahringo@redhat.com> Signed-off-by: David Teigland <teigland@redhat.com>
Diffstat (limited to 'security')
0 files changed, 0 insertions, 0 deletions