From owner-cvs-src@FreeBSD.ORG Sat Oct 4 17:51:17 2003 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DA4D116A4B3; Sat, 4 Oct 2003 17:51:17 -0700 (PDT) Received: from mail.chesapeake.net (chesapeake.net [208.142.252.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 66A5443FCB; Sat, 4 Oct 2003 17:51:16 -0700 (PDT) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost) by mail.chesapeake.net (8.11.6/8.11.6) with ESMTP id h950pFX47993; Sat, 4 Oct 2003 20:51:15 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Sat, 4 Oct 2003 20:51:15 -0400 (EDT) From: Jeff Roberson To: Jeff Roberson In-Reply-To: <200310050035.h950ZfWK050548@repoman.freebsd.org> Message-ID: <20031004204825.J99666-100000@mail.chesapeake.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern vfs_subr.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2003 00:51:18 -0000 This is probably the last of it for a little while. I have some other locked bits in my tree, but I'm not quite ready to commit them yet. What I've been working on is locking the lists that don't use v_usecount to protect them. This includes the free list, spec hash, syncer list, mnt vnode list, and the name cache. The actual datastructures are all protected, but they almost all have races with vnode recycling and forced unmounts. On Sat, 4 Oct 2003, Jeff Roberson wrote: > jeff 2003/10/04 17:35:41 PDT > > FreeBSD src repository > > Modified files: > sys/kern vfs_subr.c > Log: > - Solve a LOR with the sync_mtx by using the VI_ONWORKLST flag to determine > whether or not the sync failed. This could potentially get set between > the time that we VOP_UNLOCK and VI_LOCK() but the race would harmelssly > lead to the sync being delayed by an extra 30 seconds. If we do not move > the vnode it could cause an endless loop if it continues to fail to sync. > - Use vhold and vdrop to stop the vnode from changing identities while we > have it unlocked. Other internal vfs lists are likely to follow this > scheme. > > Revision Changes Path > 1.462 +12 -6 src/sys/kern/vfs_subr.c >