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
F103004193: D35639.diff
Tue, Nov 19, 5:30 PM
Unknown Object (File)
Mon, Oct 21, 4:40 AM
Unknown Object (File)
Mon, Oct 21, 4:40 AM
Unknown Object (File)
Mon, Oct 21, 4:40 AM
Unknown Object (File)
Mon, Oct 21, 4:40 AM
Unknown Object (File)
Mon, Oct 21, 4:18 AM
Unknown Object (File)
Oct 13 2024, 1:07 AM
Unknown Object (File)
Sep 25 2024, 8:38 AM
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