[Bug 200585] [nlm] Fatal trap 9 when printing out KASSERT trying to run umount -f on an NFS share while it's trying to print out "lockd not responding" in nlm(4)

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200585

--- Comment #8 from Rick Macklem <rmacklem at FreeBSD.org> ---
Although adding a ref count to the cred struct may
help avoid some crashes, the code that prints out
the message uses both the mount structure and the
NFS specific one hanging off of mnt_data.

Unfortunately adding a ref count to the mount structure
via vfs_ref(mp) only delays freeing of *mp and not *mnt_data.
Also, vfs_destroy_mount() waits for the ref count on the mount
structure to go to 0 and, as such, "umount -f" won't complete
until the lock RPC completes.

If the ref count on the mount structure only free'd the structure
and substructure hanging off of mnt_data, then adding a ref count
to the mount structure before the VOP_UNLOCK() could avoid the
crashes.
Maybe this VFS change should be considered?

Also, doing "umount -f" on a file system using locking could
leave "dangling locks" on files. In theory, rpc.statd should
eventually notice that the host isn't responding and get rid
of these file locks, but I wouldn't bet on it.

I suppose the dangers of using "umount -f" while running
rpc.lockd should be documented. I'll come up with a man page
patch for that.

-- 
You are receiving this mail because:
You are the assignee for the bug.