<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><font face="monospace, monospace"><br></font><div><font 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></font><br>Thread2:<div><br><font face="monospace, monospace">syscall <br>rcu_barrier_qsbr <br>destroy_all<br>main<br></font><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"><font color="#888888"><br><br><br>-- <br>Cheers,<br>Evgeniy</font></span></div></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Cheers,<br>Evgeniy</div>
</div>