K 10
svn:author
V 7
glebius
K 8
svn:date
V 27
2012-04-09T14:16:24.012688Z
K 7
svn:log
V 1577
Locking pfsync(4):

- We have a couple of mutexes for pfsync, main softc mutex
  that locks all softc queues and configuration. It can be
  obtained when holding lock on a state ID hash row in pf(4).
  And a separate mutex for bulk updates configuration in softc.
  The bulk update code needs to lock its mutex prior to
  PF_STATE_LOCK(st), thus I used a separate one.
- The deferral code was a tricky one, and its locking still
  has problems: pfsync_defer_tmo() modifies state flags w/o
  obtaining PF_STATE_LOCK, since that would be lock order
  violation.
  - Deferred packets, when sent, are queued and sent in pfsyncintr(),
  since sending them directly from pf(4) processing path or from
  callout leads to LORs and recursions. Dropping PF_LOCK() as old code
  did, isn't safe either.
  - Deferring timeouts are drained in pfsync_clone_destroy().
- pfsync_ioctl() and its descendants rewritten, so that we don't need
  unsafe temporary lock drop.

Cleaning pfsync(4):
- Removed UMA zone. It was used to allocate 32 byte update requests,
  and 104 byte deferrals. Since deferrals are off by default, using
  a > 100 byte zone for 32 byte items is a memory waste. And since
  malloc(9) for small chunks is backed by UMA, and our update
  requests aren't any special, it is more efficient to use malloc
  for them.
- Sorted softc fields by their meaning, easier to read by newcomer now.
- Removed pfsync_up(), pfsync_timeout(), pfsync_sysctl().
- Removed some write only variables.
- Removed pfsyncstart(), pfsync_if_dequeue().
  Shouldn't pfsync_output() be removed, too?

END