Summary: | [nfs] [nlm] [lor] newnfs/allproc lock order reversal on NFS mount recovery | ||
---|---|---|---|
Product: | Base System | Reporter: | Gavin Atkinson <gavin> |
Component: | kern | Assignee: | freebsd-fs (Nobody) <fs> |
Status: | Closed DUPLICATE | ||
Severity: | Affects Only Me | CC: | rmacklem |
Priority: | --- | ||
Version: | 10.2-BETA2 | ||
Hardware: | Any | ||
OS: | Any |
Description
Gavin Atkinson
![]() ![]() 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 *** |