Date: Sun, 20 Sep 2015 21:41:08 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 203134] [nfs] [nlm] [lor] newnfs/allproc lock order reversal on NFS mount recovery Message-ID: <bug-203134-3630-KChDqluTFh@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-203134-3630@https.bugs.freebsd.org/bugzilla/> References: <bug-203134-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=203134 Rick Macklem <rmacklem@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rmacklem@FreeBSD.org Status|New |Closed Resolution|--- |DUPLICATE --- Comment #1 from Rick Macklem <rmacklem@FreeBSD.org> --- The info below doesn't seem to show where the locks are acquired in the other order. The NFS client (for NFSv4) and the NLM first lock the NFS vnode and then the "proc" related lock(s). Since I do not believe the NFS subsystem and NLM (not really a part of NFS, but a separate protocol) ever first locks the proc structure and then a vnode, I don't think and deadlock can occur. If someone knows of a way that the generic kernel code could lock an NFS client vnode after acquiring a proc lock, please let me know. I do know that it isn't practical to "fix" these LORs, but I do not believe that they can cause deadlocks. If I find out where harmless LORs are listed, I'll add these. rick ps: Although 203133 isn't the same LOR, the same story applies to both. *** This bug has been marked as a duplicate of bug 203133 *** -- 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-203134-3630-KChDqluTFh>