diff options
author | Alexander Aring <aahringo@redhat.com> | 2022-04-04 16:06:45 -0400 |
---|---|---|
committer | David Teigland <teigland@redhat.com> | 2022-04-06 14:02:58 -0500 |
commit | 401597485cfc702ee75c4dc73345dcfcdb002d04 (patch) | |
tree | ca9a4c4ebce9bd2b589076ee5978b70112311531 /security | |
parent | e91ce03b27b6815cae064bb3d608b7cd26f3fab4 (diff) | |
download | linux-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