diff options
author | kib <kib@FreeBSD.org> | 2011-07-13 21:07:41 +0000 |
---|---|---|
committer | kib <kib@FreeBSD.org> | 2011-07-13 21:07:41 +0000 |
commit | e3d33b853d78d9c9665b164f2343f53be9338b44 (patch) | |
tree | 450324ad4ac0e9626ed44ee9323a092155663468 /sbin/shutdown | |
parent | 6620a4474b278d01edd0ca6fc446c01f9fa8b619 (diff) | |
download | FreeBSD-src-e3d33b853d78d9c9665b164f2343f53be9338b44.zip FreeBSD-src-e3d33b853d78d9c9665b164f2343f53be9338b44.tar.gz |
While fixing the looping of a thread while devfs vnode is reclaimed,
r179247 introduced a possibility of devfs_allocv() returning spurious
ENOENT. If the vnode is selected by vnlru daemon for reclamation, then
devfs_allocv() can get ENOENT from vget() due to devfs_close() dropping
vnode lock around the call to cdevsw d_close method.
Use LK_RETRY in the vget() call, and do some part of the devfs_reclaim()
work in devfs_allocv(), clearing vp->v_data and de->de_vnode. Retry the
allocation of the vnode, now with de->de_vnode == NULL.
The check vp->v_data == NULL at the start of devfs_close() cannot be
affected by the change, since vnode lock must be held while VI_DOOMED
is set, and only dropped after the check.
Reported and tested by: Kohji Okuno <okuno.kohji jp panasonic com>
Reviewed by: attilio
MFC after: 3 weeks
Diffstat (limited to 'sbin/shutdown')
0 files changed, 0 insertions, 0 deletions