Re: passive references

[Ryota Ozaki <ozaki-r%netbsd.org@localhost>]

On Sat, Jan 30, 2016 at 12:43 AM, Taylor R Campbell
<riastradh%netbsd.org@localhost> wrote:
>    Date: Fri, 29 Jan 2016 17:39:13 +0900
>    From: Ryota Ozaki <ozaki-r%netbsd.org@localhost>
>
>    I'm thinking applying psref to bridge member list
>    that is now using its own version of similar mechanism
>    (psz + refcount).
>
> Nice!  That sounds like a good application to test, since most of the
> work has been done already and it's mainly a matter of replacing a
> refcount by a psref.

I'm happy if there is a patch of psref.c to -current :)

>
>    To do so, some questions come to me:
>    - Can psref_acquire and psref_release be used in ioctl
>      handlers if we use kprempet_disable together?
>      - Bridge member lists can be accessed via ioctl
>        that runs in normal LWP context
>
> You don't need to disable preemption -- sleeping and preemption are
> both OK -- but you do need to make sure you don't switch CPUs while
> you hold a psref.
>
> For softints, and for kthreads bound to a CPU, that's always
> guaranteed.  For LWPs that are not bound, e.g. most user LWPs, it may
> suffice to do something like this:
>
> int bound = curlwp->l_pflag & LP_BOUND;
> curlwp->l_pflag |= LP_BOUND;
> ...acquire and release psref...
> curlwp->l_pflag ^= bound ^ LP_BOUND;
>
> I *think* it is not necessary to kpreempt_disable() or anything in
> order for an LWP to touch its own pflag.  And I think it is safe to do
> this in soft or hard interrupt context too, since it will be undone by
> the time the interrupt returns.  (Of course, there's no reason to
> acquire a psref in hard interrupt context -- you can't sleep anyway!)

I see.

>
> Someone more familiar with the inner workings of LWPs and the
> scheduler should review this, though.  And maybe we should invent a
> name lwp_bind/lwp_unbind for this pattern.

I agree; open accesses to l_pflag looks not good idea.

>
>    - Can we use pserialize_read_{enter,exit} for psref
>      objects?
>      - Not all critical sections of a bridge member list
>        are sleepable. If we can use pserialize_read_{enter,exit}
>        directly for non-sleepable critical sections, it makes
>        the code simple and efficient
>
> Yes.  Normally you would acquire a psref inside a pserialize read
> section -- and the only reason you would acquire a psref at all,
> instead of using just plain pserialize, is to allow sleeping or
> preemption while you hold the psref.

Oops. Your example has the answer already!
Anyway thank you for the answer. I got it.

  ozaki-r