<html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><div>This is because we use call_rcu internally to trigger the hash table<br></div><div>resize.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>In cds_lfht_destroy, we start by waiting for "in-flight" resize to complete.<br data-mce-bogus="1"></div><div>Unfortunately, this requires that call_rcu worker thread progresses. If<br></div><div>cds_lfht_destroy is called from the call_rcu worker thread, it will wait<br data-mce-bogus="1"></div><div>forever.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>One alternative would be to implement our own worker thread scheme<br data-mce-bogus="1"></div><div>for the rcu HT resize rather than use the call_rcu worker thread. This</div><div>would simplify cds_lfht_destroy requirements a lot.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>Ideally I'd like to re-use all the call_rcu work dispatch/worker handling<br data-mce-bogus="1"></div><div>scheme, just as a separate work queue.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>Thoughts ?<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>Thanks,<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>Mathieu<br data-mce-bogus="1"></div><div><br></div><span id="zwchr" data-marker="__DIVIDER__">----- On Oct 19, 2016, at 6:03 AM, Evgeniy Ivanov <i@eivanov.com> wrote:<br></span><div data-marker="__QUOTED_TEXT__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div dir="ltr">Sorry, found partial answer in docs which state that cds_lfht_destroy should not be called from a call_rcu thread context. Why does this limitation exists?</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 19, 2016 at 12:56 PM, Evgeniy Ivanov <span dir="ltr"><<a href="mailto:i@eivanov.com" target="_blank">i@eivanov.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<br><br>Each node of top level rculfhash has nested rculfhash. Some thread clears the top level map and then uses rcu_barrier() to wait until everything is destroyed (it is done to check leaks). Recently it started to dead lock sometimes with following stacks:<br><br>Thread1:<br><span style="font-family: monospace,monospace;" data-mce-style="font-family: monospace,monospace;" face="monospace, monospace"><br></span><div><span style="font-family: monospace,monospace;" data-mce-style="font-family: monospace,monospace;" face="monospace, monospace">__poll<br>cds_lfht_destroy <---- nested map<br>...<br>free_Node(rcu_head*) <----- node of top level map<br>call_rcu_thread<br></span><br>Thread2:<div><br><span style="font-family: monospace,monospace;" data-mce-style="font-family: monospace,monospace;" face="monospace, monospace">syscall <br>rcu_barrier_qsbr <br>destroy_all<br>main<br></span><br><br>Did call_rcu_thread dead lock with barrier thread? Or is it some kind of internal deadlock because of nested maps?<span class="HOEnZb"><span style="color: #888888;" data-mce-style="color: #888888;" color="#888888"><br><br><br>-- <br>Cheers,<br>Evgeniy</span></span></div></div></div>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature">Cheers,<br>Evgeniy</div>
</div>
<br>_______________________________________________<br>lttng-dev mailing list<br>lttng-dev@lists.lttng.org<br>https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev<br></blockquote></div><br><div data-marker="__SIG_POST__">-- <br></div><div>Mathieu Desnoyers<br>EfficiOS Inc.<br>http://www.efficios.com</div></div></body></html>