e5cffdd34b
Currently several paths in the NFS client upgrade the shared vnode lock to exclusive, which might cause temporal dropping of the lock. This action appears to be fatal for nullfs mounts over NFS. If the operation is performed over nullfs vnode, then bypassed down to NFS VOP, and the lock is dropped, other thread might reclaim the upper nullfs vnode. Since on reclaim the nullfs vnode lock and NFS vnode lock are split, the original lock state of the nullfs vnode is not restored. As result, VFS operations receive not locked vnode after a VOP call. Stop upgrading the vnode lock when we check the consistency or flush buffers as result of detected inconsistency. Instead, allocate a new lockmgr lock for each NFS node, which is locked exclusive instead of the vnode lock upgrade. In other words, the other parallel modification of the vnode are excluded by either vnode lock conflict or exclusivity of the new lock when the vnode lock is shared. Also revert r316529 because now the vnode cannot be reclaimed during ncl_vinvalbuf(). In collaboration with: pho Reviewed by: rmacklem Reported and tested by: pho Sponsored by: The FreeBSD Foundation MFC after: 2 weeks Differential revision: https://reviews.freebsd.org/D12083 |
||
---|---|---|
.. | ||
autofs | ||
cd9660 | ||
cuse | ||
deadfs | ||
devfs | ||
ext2fs | ||
fdescfs | ||
fifofs | ||
fuse | ||
msdosfs | ||
nandfs | ||
nfs | ||
nfsclient | ||
nfsserver | ||
nullfs | ||
procfs | ||
pseudofs | ||
smbfs | ||
tmpfs | ||
udf | ||
unionfs |