[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: RFC: localcount_hadref() or localcount_trydarin()
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().
> 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
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....
Internet Initiative Japan Inc.
Device Engineering Section,
IoT Platform Development Department,
Kengo NAKAHARA <k-nakahara%iij.ad.jp@localhost>
Main Index |
Thread Index |