Date: Fri, 16 Jul 2010 20:23:24 +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_softdep.c ffs_vfsops.c Message-ID: <201007162024.o6GKO7OJ094856@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
jhb 2010-07-16 20:23:24 UTC
FreeBSD src repository
Modified files: (Branch: RELENG_7)
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_softdep.c ffs_vfsops.c
Log:
SVN rev 210173 on 2010-07-16 20:23:24Z 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 into 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.
The softupdates code also toggles LK_NOSHARE in one function to close a
race with snapshots. Fix this code to grab the interlock while fiddling
with lk_flags.
Revision Changes Path
1.15.2.10 +4 -1 src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c
1.150.2.6 +3 -1 src/sys/fs/cd9660/cd9660_vfsops.c
1.48.2.9 +4 -1 src/sys/fs/udf/udf_vfsops.c
1.211.2.10 +6 -0 src/sys/ufs/ffs/ffs_softdep.c
1.329.2.22 +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?201007162024.o6GKO7OJ094856>