When growfs grows a mounted filesystem it suspends writes to it through
/dev/ufssuspend, and the suspension is lifted when that descriptor is
closed.

If growfs crashes while the filesystem is suspended, the kernel tries
to write the core dump to that same filesystem (the default when growfs
runs from a directory on it) and waits forever for the suspension to
end.  growfs can't be killed and every other write to the filesystem
blocks.

I first hit this with growfs -y / on a Raspberry Pi 3 running 15.1,
where growfs crashes because of the Cortex-A53 erratum (PR 296240).
ssh logins hung, nothing could write to /, and I had to power cycle.

It reproduces on stock 15.1-RELEASE-p3 by crashing growfs on purpose:

  mdconfig -a -t vnode -f /var/tmp/gfs.img     # 3 GB file
  gpart create -s gpt md0; gpart add -t freebsd-ufs -s 512m md0
  newfs -U /dev/md0p1; mount /dev/md0p1 /mnt/t
  gpart resize -i 1 md0
  cd /mnt/t; growfs -y /dev/md0p1 &
  # once growfs has /dev/ufssuspend open:
  kill -SEGV %1

growfs then sits in the suspfs wait, and touch /mnt/t/x blocks too:

  PID STAT WCHAN  COMMAND
 1426 D+   suspfs growfs -y /dev/md0p1

 growfs ... _sleep vn_start_write vn_open_cred core_vn_extend sigexit
     postsig ...

Possible fixes: growfs could set RLIMIT_CORE to 0 before suspending the
filesystem (the kernel skips the dump entirely in that case), but the
general fix is probably for the core dump code not to wait on a
suspended filesystem.  hv_vss_daemon also uses /dev/ufssuspend.