summaryrefslogtreecommitdiffstats
path: root/sys/kern/kern_exec.c
diff options
context:
space:
mode:
authoriedowse <iedowse@FreeBSD.org>2002-12-29 18:30:49 +0000
committeriedowse <iedowse@FreeBSD.org>2002-12-29 18:30:49 +0000
commit1ec5f03e6d974f74f3960788e6bf478e5cce3bf1 (patch)
tree695f7d1dc64135abdddb6910423929c8aa931922 /sys/kern/kern_exec.c
parentf387a3fcba910b45d8dc3c0443d8351eedc0bf6e (diff)
downloadFreeBSD-src-1ec5f03e6d974f74f3960788e6bf478e5cce3bf1.zip
FreeBSD-src-1ec5f03e6d974f74f3960788e6bf478e5cce3bf1.tar.gz
Add a new vnode flag VI_DOINGINACT to indicate that a VOP_INACTIVE
call is in progress on the vnode. When vput() or vrele() sees a 1->0 reference count transition, it now return without any further action if this flag is set. This flag is necessary to avoid recursion into VOP_INACTIVE if the filesystem inactive routine causes the reference count to increase and then drop back to zero. It is also used to guarantee that an unlocked vnode will not be recycled while blocked in VOP_INACTIVE(). There are at least two cases where the recursion can occur: one is that the softupdates code called by ufs_inactive() via ffs_truncate() can call vput() on the vnode. This has been reported by many people as "lockmgr: draining against myself" panics. The other case is that nfs_inactive() can call vget() and then vrele() on the vnode to clean up a sillyrename file. Reviewed by: mckusick (an older version of the patch)
Diffstat (limited to 'sys/kern/kern_exec.c')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud