Close what might be a race, and assert that it doesn't happen:
When we do a lookup, we first try without the lock, if this gives us a refcnt==0 objhead, we try again, with the lock. When we deref an objhead, we would decrement the refcnt, holding oh->mtx, then lock the critbit-lock and remove it from the tree. It might be possible for a locked lookup to find an oh we just decremented the refcnt off, and we did not check for refcnt==0 in that case. Fix this, by removing the oh from the tree, holding the critbit-lock, before decrementing the refcnt. This way, a locked lookup can never find a refcnt==0 oh in the tree, and the unlocked lookup still catches this with the refcnt==0 check. git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@4549 d4fa192b-c00b-0410-8231-f00ffab90ce4
Showing
Please register or sign in to comment