Re: shared lwkt locks
Matthew Dillon <[email protected]> Thu, 16 Jul 2015 21:42:46 -0700
| Newsgroups | gmane.os.dragonfly-bsd.kernel |
|---|---|
| Message-ID | <CAOZ7CpC6KOtQmLX_yD0wSucw6YO0KBwp8RcNbnd33_wKMx=_Bw@mail.gmail.com> |
That warning is in comments, it's documenting the fact that vm_object_drop() might be called reentrantly due to potentially being locked shared. -Matt On Thu, Jul 16, 2015 at 9:40 PM, Matthew Dillon <[email protected]> wrote: > 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. > > -Matt > > On Thu, Jul 16, 2015 at 6:25 PM, Alex Merritt <[email protected]> > wrote: > >> Matt, >> >> 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: >> >> vm_object_hold_shared(A) >> vm_object_hold_shared(A) >> vm_object_drop(A) >> vm_object_drop(A) // <-- panic >> >> The panic is here: http://bxr.su/DragonFly/sys/vm/vm_object.c#332 >> >> Is this panic expected behavior (i.e. does a release relinquish any >> number of prior shared lock acquires to a token)? >> >> The location of the warning in comments I am referring to is here: >> >> http://bxr.su/DragonFly/sys/vm/vm_object.c#320 >> >> -Alex >> >> >> On Thu, Jul 16, 2015 at 5:54 PM, Matthew Dillon <[email protected]> >> wrote: >> >>> 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. >>> >>> 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. >>> >>> I'm not sure which warning you are talking about, where in >>> vm_object_drop() ? >>> >>> -Matt >>> >>> On Thu, Jul 16, 2015 at 5:31 PM, Alex Merritt <[email protected]> >>> wrote: >>> >>>> Hi, >>>> >>>> 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. >>>> >>>> Thanks, >>>> Alex >>>> >>> >>> >> >