Date: Fri, 05 Jun 2015 12:17:37 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [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) Message-ID: <bug-200585-3630-wfgpaZU0ZO@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-200585-3630@https.bugs.freebsd.org/bugzilla/> References: <bug-200585-3630@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200585 --- Comment #8 from Rick Macklem <rmacklem@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-200585-3630-wfgpaZU0ZO>