Hi, On 2017/06/09 17:18, Paul Goyette wrote: > On Fri, 9 Jun 2017, Kengo NAKAHARA wrote: >> I tried using localcount(9) for opencyrpto(9) to avoid detach encryption >> drivers. While I implement that, I want to something to use KASSERT which >> ensure someone have reference or not. >> In addition, localcount_drain() waits forever if someone has had reference. >> So, I want to function which returns in not so long time regardless of >> someone has reference or not. In other words, I want some function like >> mutex_tryenter() for mutex_enter(). // snip > I think you are trying to abuse the design of localcount(9) :) > > The problem here is, whether or not you return immediately, the > localcount has been marked for draining, and nothing else will ever > be able to acquire it. You've already set the totalp pointer to a > non-NULL value, so any further attempts to call localcount_drain() > or localcount_hadref() will fail in the KASSERT. > > So, let's assume that you call localcount_hadref(); if it returns > true you immediately call localcount_fini() (since it has already > been drained). But what happens if it returns false? You can > never go back and check the "total" again, so you will never know > when it is safe to call localcount_fini(). > > >> In the other design, rename the function name to "localcount_trydrain()" >> and invert return value true/false. > > This has the same problem. You WILL always drain the localcount, > whether or not you return quickly. But if the localcount is not > already drained, you will never be able to check again. > > Furthermore, the totalp pointer points to a value _on_the_stack_ > and the pointer is stored in the localcount itself. So, if you > allow the routine to return "early", there might still be other > places that hold references to this localcount, and they will > eventually call localcount_release(). When that happens, they > will try to decrement the total value, and this may corrupt the > stack of some other routine! > > > As I wrote in the man-page, draining the localcount is a one-shot > operation - once you start the process of draining (by setting the > totalp and issuing the xcall) you cannot stop the process, nor can > you restart the process (to get an updated count). Additionally, > once you start the process of draining, you _must_ wait for it to > complete;
Thank you for your detailed comments! I read man again carefully..., yes, to the last. Hmm... I see. I rethink opencrypto(9) design to use not only localcount(9) but also any other tools to avoid waiting. Anyway, thank you for your expositions. > you cannot escape. > > :) Oh, my resistance is futile.... Thanks, -- ////////////////////////////////////////////////////////////////////// Internet Initiative Japan Inc. Device Engineering Section, IoT Platform Development Department, Network Division, Technology Unit Kengo NAKAHARA <k-nakah...@iij.ad.jp>
