pserialize-safe queue(3) alternative

[Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost>]

The attached pslist.h implements a pserialize-safe alternative to the
LIST_* operations in queue(3), with example use in pslist.c:

- The PSLIST_WRITER_* operations are safe to use in an exclusive
writer to publish and unpublish elements -- they issue membar_producer
after each element is initialized and before its pointer is exposed to
other CPUs.

(Issuing membar_producer before or after LIST_INSERT_* is not
sufficient because the ordering of writes inside it matters too.)

- The PSLIST_READER_* operations are safe to use in a non-exclusive
pserialize read section -- they issue membar_datadep_consumer after
retrieving each element pointer and before allowing the caller to use
the data it points to.

(Issuing membar_datadep_consumer after LIST_FIRST/LIST_NEXT or inside
LIST_FOREACH is sufficient, but easy to forget.)

Parts of the effort to parallelize the network stack are currently
waiting for these operations [1], and bugs have crept into bridge(4)
because it is easy to naively use LIST_* without noticing that the
necessary memory barriers aren't there.

I previously proposed adding *_PSZ variants to the queue(3)
operations [3].  The main objections were:

- It is too easy to mistakenly mix the non-_PSZ operations with the
_PSZ ones.  A different API altogether prevents this.

- Adding _PSZ variants to all the queue(3) data structures is a waste
because only lists are likely to be useful for this application.

- The entirely macro-based implementation of queue(3) is archaic,
error-prone, and confusing for debuggers.  pslist.h has two static
type definitions, instead of macros that expand into them, and the
bulk of the logic is written in inline functions, not macros.

This API requires one change to the PSLIST_*_FOREACH macro -- you must
specify the type of the element -- although if we used typeof (is that
allowed?) it would not be necessary.

Thoughts?  Objections?


[1] https://mail-index.netbsd.org/tech-kern/2016/02/15/msg020219.html
[2] https://mail-index.netbsd.org/tech-kern/2016/02/12/msg020203.html
[3] https://mail-index.netbsd.org/tech-kern/2014/11/21/msg018055.html