Date: Fri, 16 Jul 2010 19:20:20 +0000 (UTC) From: John Baldwin <jhb@FreeBSD.org> To: cvs-src-old@freebsd.org Subject: cvs commit: src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs zfs_znode.c src/sys/fs/cd9660 cd9660_vfsops.c src/sys/fs/udf udf_vfsops.c src/sys/ufs/ffs ffs_vfsops.c Message-ID: <201007161921.o6GJLEhs089277@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
jhb 2010-07-16 19:20:20 UTC
FreeBSD src repository
Modified files:
sys/cddl/contrib/opensolaris/uts/common/fs/zfs zfs_znode.c
sys/fs/cd9660 cd9660_vfsops.c
sys/fs/udf udf_vfsops.c
sys/ufs/ffs ffs_vfsops.c
Log:
SVN rev 210171 on 2010-07-16 19:20:20Z by jhb
When the MNTK_EXTENDED_SHARED mount option was added, some filesystems were
changed to defer the setting of VN_LOCK_ASHARE() (which clears LK_NOSHARE
in the vnode lock's flags) until after they had determined if the vnode was
a FIFO. This occurs after the vnode has been inserted a VFS hash or some
similar table, so it is possible for another thread to find this vnode via
vget() on an i-node number and block on the vnode lock. If the lockmgr
interlock (vnode interlock for vnode locks) is not held when clearing the
LK_NOSHARE flag, then the lk_flags field can be clobbered. As a result
the thread blocked on the vnode lock may never get woken up. Fix this by
holding the vnode interlock while modifying the lock flags in this case.
MFC after: 3 days
Revision Changes Path
1.32 +4 -1 src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c
1.166 +2 -0 src/sys/fs/cd9660/cd9660_vfsops.c
1.64 +4 -1 src/sys/fs/udf/udf_vfsops.c
1.374 +2 -0 src/sys/ufs/ffs/ffs_vfsops.c
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201007161921.o6GJLEhs089277>