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
Unknown Object (File)
Jan 14 2024, 10:05 AM
Unknown Object (File)
Dec 20 2023, 2:05 AM
Unknown Object (File)
Nov 29 2023, 10:35 PM
Unknown Object (File)
Sep 26 2023, 7:29 AM
Unknown Object (File)
Jul 10 2023, 12:16 AM
Unknown Object (File)
Jul 3 2023, 11:30 AM
Unknown Object (File)
Jul 3 2023, 11:29 AM
Unknown Object (File)
Jul 3 2023, 11:28 AM
Subscribers

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

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