pktgen: Unbreak compile
hammer2 - serialized flush work part 4

* Hardlink helper functions now take and return hammer2_chain pointers
  instead of messing with hammer2_inode's, which simplifies matters
  greatly.

* Major cleanup of the hardlink handling code.

* Get hardlink creation/deletion mostly working as expected again.
  There is still an issue with hammer_inode aliasing (see TODO),
  and the rename-directory-to-some-parent hardlink issue has not been
  addressed yet.
kernel - Fix memory leak on iocom terminaion

* freerd_state was being cleaned up by the reader thread, but during
  decomissioning the writer thread can simulate incoming packets
  to cleanly shutdown open transactions, and this can reload
  freerd_state.

* Move the cleanup for freerd_state and freewr_state out of the
  reader/writer threads and into kdmsg_iocom_uninit() proper.

* Fixes dangling 112 bytes of memory left allocated after uninit.
kernel - cycle vnode in cache_unlink()

* cache_unlink() and cache_rename() are called by VFS's to update the
  namecache after a file deletion or rename.  cache_rename() also calls
  cache_unlink().

* Add code to this function which cycles any vnode attached to the
  namecache entry for the case where its refs are 0.  This will
  trigger VOP_INACTIVE and allow the VFS to detect file deletions.

  Generally speaking this means that VFS's no longer have to detect
  deleted files in code paths outside of VOP_INACTIVE w/regards to
  forcing a reclaim on the vnode.

* HAMMER2 now depends on this behavior.  The change in behavior allows
  HAMMER2 to do away with inode backpointers from chain structures,
  greatly simplifying the code and removing a chicken-egg dependency.

* Other VFSs (HAMMER, TMPFS, UFS) may be adjusted in the future but for
  now their file deletion code outside of VOP_INACTIVE is being left
  intact.
kernel - Fix kernel panic caused by rename race

* kern_rename() must temporarily unlock the source ncp when resolving the
  target ncp, and will sometimes have to temporarily unlock the target ncp
  when relocking both.  This can race against a topological removal of one
  or both ncp's, resulting in incorrect operation or a panic due to a
  NULL vp.

* Detect the case and return EAGAIN if the ncp's have been marked NCF_DESTROYED
  or if fromncp loses its vp resolution.  Callers detect the EAGAIN and retry
  the operation.

Reported-by: ftigeot
Merge branch 'master' into gsocdrm_alter