Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 23 Aug 2010 08:40:19 -0400
From:      John Baldwin <jhb@freebsd.org>
To:        src-committers@freebsd.org
Cc:        svn-src-stable@freebsd.org, svn-src-all@freebsd.org, svn-src-stable-7@freebsd.org
Subject:   Re: svn commit: r211533 - in stable/7/sys: cddl/contrib/opensolaris/uts/common/fs/zfs fs/cd9660 fs/udf kern sys ufs/ffs
Message-ID:  <201008230840.20016.jhb@freebsd.org>
In-Reply-To: <201008202058.o7KKwvdp047830@svn.freebsd.org>
References:  <201008202058.o7KKwvdp047830@svn.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Friday, August 20, 2010 4:58:57 pm John Baldwin wrote:
> Author: jhb
> Date: Fri Aug 20 20:58:57 2010
> New Revision: 211533
> URL: http://svn.freebsd.org/changeset/base/211533
> 
> Log:
>   Revert 210173 as it did not properly fix the bug.  It assumed that the
>   VI_LOCK() for a given vnode was used as the internal interlock for that
>   vnode's v_lock lockmgr lock.  This is not the case.  Instead, add dedicated
>   routines to toggle the LK_NOSHARE and LK_CANRECURSE flags.  These routines
>   lock the lockmgr lock's internal interlock to synchronize the updates to
>   the flags member with other threads attempting to acquire the lock.  The
>   VN_LOCK_A*() macros now invoke these routines, and the softupdates code
>   uses these routines to temporarly enable recursion on buffer locks.

This is a direct commit rather than an MFC as the lockmgr implementation is
completely different in relation to this bug than in 8.x and later.

-- 
John Baldwin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201008230840.20016.jhb>