Re: passive references

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

   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.

   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!)

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.

   - 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.

   BTW psref recalls me hazard pointers (and OpenBSD's SRP).

It is similar to hazard pointers.  I think psref is considerably
simpler, perhaps at a higher cost per item for the GC phase.