<div dir="ltr"><div>You are doing something more than what you coded above and it is causing the object's hold count to go negative on the second drop.  That particular panic is not related to the token itself.   It looks to me like the object must have been dropped more times than it was held.<br><br></div>-Matt<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 16, 2015 at 6:25 PM, Alex Merritt <span dir="ltr"><<a href="mailto:merritt.alex@gmail.com" target="_blank">merritt.alex@gmail.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">Matt,<div><br></div><div>Thanks. I am working with the locks in the order as you described. I am specifically trying to understand if the order also applies to shared lock acquisitions, as I am experiencing a panic when I drop a lock the second time, after having performed two shared acquisitions:<br></div><div><br></div><div>vm_object_hold_shared(A)</div><div>vm_object_hold_shared(A)</div><div>vm_object_drop(A)</div><div>vm_object_drop(A) // <-- panic</div><div><br></div><div>The panic is here: <a href="http://bxr.su/DragonFly/sys/vm/vm_object.c#332" target="_blank">http://bxr.su/DragonFly/sys/vm/vm_object.c#332</a></div><div><br></div><div>Is this panic expected behavior (i.e. does a release relinquish any number of prior shared lock acquires to a token)?</div><div><br></div><div>The location of the warning in comments I am referring to is here:</div><div><br></div><div><a href="http://bxr.su/DragonFly/sys/vm/vm_object.c#320" target="_blank">http://bxr.su/DragonFly/sys/vm/vm_object.c#320</a><br></div><div><br></div><div>-Alex</div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 16, 2015 at 5:54 PM, Matthew Dillon <span dir="ltr"><<a href="mailto:dillon@backplane.com" target="_blank">dillon@backplane.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"><div>Lock releases must match lock acquisitions.  lwkt_tokens have an additional requirement that lock releases must be performed in exactly the reverse order as the acquires.  So if you acquire A, B, C, B, X, Y  you have to release in reverse, Y, X , B, C, B, A.<br><br></div><div>Shared tokens are very dangerous and must be used carefully.  The vm_object code is the most complex code in the kernel that uses shared tokens, and as you can see by reading it, it can get nasty because a particular token cannot mix shared and exclusive use in the same thread.<br><br></div><div>I'm not sure which warning you are talking about, where in vm_object_drop() ?<br></div><div><br></div>-Matt<br></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 16, 2015 at 5:31 PM, Alex Merritt <span dir="ltr"><<a href="mailto:merritt.alex@gmail.com" target="_blank">merritt.alex@gmail.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,<div><br></div><div>Does releasing a lwkt_token release all prior gettoken_shared invocations to that lock, or is one required to perform reltoken as many times as you've performed gettoken_shared? There is a warning in vm_object_drop that the lock may be shared -- I was wondering what exactly that warning is meant to warn against. Apologies if the answer is apparent somewhere.</div><div><br></div><div>Thanks,</div><div>Alex</div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div></div>
</blockquote></div><br></div>