Page MenuHomeFreeBSD

vfs_op_exit(): assert that mnt_vfs_ops stays non-zero for unmount or suspend
ClosedPublic

Authored by kib on Jun 28 2022, 7:23 PM.
Tags
None
Referenced Files
F142383125: D35639.diff
Mon, Jan 19, 9:39 AM
Unknown Object (File)
Mon, Dec 29, 5:24 AM
Unknown Object (File)
Dec 10 2025, 9:06 PM
Unknown Object (File)
Dec 2 2025, 12:04 AM
Unknown Object (File)
Nov 26 2025, 11:52 PM
Unknown Object (File)
Nov 25 2025, 10:32 PM
Unknown Object (File)
Nov 20 2025, 10:26 PM
Unknown Object (File)
Nov 3 2025, 11:05 PM
Subscribers

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

kib requested review of this revision.Jun 28 2022, 7:23 PM
sys/kern/vfs_mount.c
1771

did you mean to put this after the decrement? as is it always passes since it is already asserted that the count is at least 1

i think for now it will most sense to change it into an if statement and include the same debug info as the already existing panic

kib marked an inline comment as done.

Correct the check, it must be > 1.
Add info similar to the above panic.

sys/kern/vfs_mount.c
1771

So I have a question, why vfs_op_enter() and vfs_op_exit_locked() do panic() instead of using KASSERT? What makes these conditions so special?

BTW, panic() format string must not end with "\n", and lines in vfs_op_enter() are too long.

mjg added inline comments.
sys/kern/vfs_mount.c
1771

It follows other checks in the area, for example see all the panics in vfs_mount_destroy. I don't have a strong opinion one way or the other. This probably should get a MOUNTASSERT or whatever the name in a vain similar to VNASSERT.

This revision is now accepted and ready to land.Jun 29 2022, 11:04 AM