[Asterisk-code-review] named locks: Use ao2 weakproxy find. (asterisk[master])
Richard Mudgett
asteriskteam at digium.com
Tue Oct 10 15:50:50 CDT 2017
Richard Mudgett has posted comments on this change. ( https://gerrit.asterisk.org/6711 )
Change subject: named_locks: Use ao2_weakproxy_find.
......................................................................
Patch Set 2: Code-Review-1
(1 comment)
https://gerrit.asterisk.org/#/c/6711/2/main/named_locks.c
File main/named_locks.c:
https://gerrit.asterisk.org/#/c/6711/2/main/named_locks.c@120
PS2, Line 120: lock = __ao2_weakproxy_find(named_locks, concat_key, OBJ_SEARCH_KEY | OBJ_NOLOCK,
Uh Oh.
A problem here is if named_locks gets unlocked searching for the proxy/real object we might have two threads creating proxy/real objects for the same named lock.
This is also a pre-existing problem.
Its probably easier to see with the pre-patch code:
* Thread 1 has already obtained the real lock object. (lock ref in weak-proxy and thread 1)
* Thread 2 gets named_locks and finds proxy.
* Thread 2 unlocks named_locks
* Thread 3 gets named locks and finds proxy.
* Thread 1 releases the lock ref, lock ref now 1 and grabs proxy lock, blocks on named_locks because of subscription named_lock_proxy_cb() callback trying to unlink the proxy.
* Thread 3 unlocks named_locks
* Thread 1 completes unlinking the proxy from named_locks and releases proxy lock
* Thread 2 and 3 will now create their own lock object and stick them in named_locks because the proxy is already unlinked from the real obj.
Some slight variations on thread 1 execution ordering could still result in creating multiple lock objects.
Admittedly, three thread interactions are unlikely. However, they are more likely to happen on a very busy system and leave little to no trace of what happened.
--
To view, visit https://gerrit.asterisk.org/6711
To unsubscribe, visit https://gerrit.asterisk.org/settings
Gerrit-Project: asterisk
Gerrit-Branch: master
Gerrit-MessageType: comment
Gerrit-Change-Id: I0ce8a1b7101b6caac6a19f83a89f00eaba1e9d9c
Gerrit-Change-Number: 6711
Gerrit-PatchSet: 2
Gerrit-Owner: Corey Farrell <git at cfware.com>
Gerrit-Reviewer: George Joseph <gjoseph at digium.com>
Gerrit-Reviewer: Jenkins2
Gerrit-Reviewer: Richard Mudgett <rmudgett at digium.com>
Gerrit-Comment-Date: Tue, 10 Oct 2017 20:50:50 +0000
Gerrit-HasComments: Yes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-code-review/attachments/20171010/58df3ec0/attachment.html>
More information about the asterisk-code-review
mailing list