<p>Richard Mudgett <strong>posted comments</strong> on this change.</p><p><a href="https://gerrit.asterisk.org/6711">View Change</a></p><p>Patch set 2:<span style="border-radius: 3px; display: inline-block; margin: 0 2px; padding: 4px;background-color: #ffd4d4;">Code-Review -1</span></p><p>(1 comment)</p><ul style="list-style: none; padding-left: 20px;"><li><p><a href="https://gerrit.asterisk.org/#/c/6711/2/main/named_locks.c">File main/named_locks.c:</a></p><ul style="list-style: none; padding-left: 20px;"><li><p style="margin-bottom: 4px;"><a href="https://gerrit.asterisk.org/#/c/6711/2/main/named_locks.c@120">Patch Set #2, Line 120:</a> <code style="font-family:monospace,monospace">      lock = __ao2_weakproxy_find(named_locks, concat_key, OBJ_SEARCH_KEY | OBJ_NOLOCK,</code></p><p style="white-space: pre-wrap; word-wrap: break-word;">Uh Oh.</p><p style="white-space: pre-wrap; word-wrap: break-word;">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.</p><p style="white-space: pre-wrap; word-wrap: break-word;">This is also a pre-existing problem.</p><p style="white-space: pre-wrap; word-wrap: break-word;">Its probably easier to see with the pre-patch code:</p><ul><li>Thread 1 has already obtained the real lock object. (lock ref in weak-proxy and thread 1)</li><li>Thread 2 gets named_locks and finds proxy.</li><li>Thread 2 unlocks named_locks</li><li>Thread 3 gets named locks and finds proxy.</li><li>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.</li><li>Thread 3 unlocks named_locks</li><li>Thread 1 completes unlinking the proxy from named_locks and releases proxy lock</li><li>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.</li></ul><p style="white-space: pre-wrap; word-wrap: break-word;">Some slight variations on thread 1 execution ordering could still result in creating multiple lock objects.</p><p style="white-space: pre-wrap; word-wrap: break-word;">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.</p></li></ul></li></ul><p>To view, visit <a href="https://gerrit.asterisk.org/6711">change 6711</a>. To unsubscribe, visit <a href="https://gerrit.asterisk.org/settings">settings</a>.</p><div itemscope itemtype="http://schema.org/EmailMessage"><div itemscope itemprop="action" itemtype="http://schema.org/ViewAction"><link itemprop="url" href="https://gerrit.asterisk.org/6711"/><meta itemprop="name" content="View Change"/></div></div>

<div style="display:none"> Gerrit-Project: asterisk </div>
<div style="display:none"> Gerrit-Branch: master </div>
<div style="display:none"> Gerrit-MessageType: comment </div>
<div style="display:none"> Gerrit-Change-Id: I0ce8a1b7101b6caac6a19f83a89f00eaba1e9d9c </div>
<div style="display:none"> Gerrit-Change-Number: 6711 </div>
<div style="display:none"> Gerrit-PatchSet: 2 </div>
<div style="display:none"> Gerrit-Owner: Corey Farrell <git@cfware.com> </div>
<div style="display:none"> Gerrit-Reviewer: George Joseph <gjoseph@digium.com> </div>
<div style="display:none"> Gerrit-Reviewer: Jenkins2 </div>
<div style="display:none"> Gerrit-Reviewer: Richard Mudgett <rmudgett@digium.com> </div>
<div style="display:none"> Gerrit-Comment-Date: Tue, 10 Oct 2017 20:50:50 +0000 </div>
<div style="display:none"> Gerrit-HasComments: Yes </div>