https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=299095
Bug ID: 299095
Summary: growfs: crash during an online grow leaves the
filesystem suspended
Product: Base System
Version: 15.1-RELEASE
Hardware: Any
OS: Any
Status: New
Severity: Affects Some People
Priority: ---
Component: kern
Assignee: [email protected]
Reporter: [email protected]
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.
--
You are receiving this mail because:
You are the assignee for the bug.
