From owner-freebsd-current  Tue Sep 22 10:19:59 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id KAA14597
          for freebsd-current-outgoing; Tue, 22 Sep 1998 10:19:59 -0700 (PDT)
          (envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from bright.fx.genx.net (bright.fx.genx.net [206.64.4.154])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA14559
          for <current@FreeBSD.ORG>; Tue, 22 Sep 1998 10:19:50 -0700 (PDT)
          (envelope-from bright@hotjobs.com)
Received: from localhost (bright@localhost)
	by bright.fx.genx.net (8.9.1/8.9.1) with SMTP id NAA07271;
	Tue, 22 Sep 1998 13:20:11 -0500 (EST)
	(envelope-from bright@hotjobs.com)
X-Authentication-Warning: bright.fx.genx.net: bright owned process doing -bs
Date: Tue, 22 Sep 1998 13:20:11 -0500 (EST)
From: Alfred Perlstein <bright@hotjobs.com>
X-Sender: bright@bright.fx.genx.net
To: Don Lewis <Don.Lewis@tsc.tdk.com>
cc: Luoqi Chen <luoqi@watermarkgroup.com>, current@FreeBSD.ORG
Subject: Re: Yet another patch to try for softupdates panic
In-Reply-To: <199809221323.GAA17424@salsa.gv.tsc.tdk.com>
Message-ID: <Pine.BSF.4.02A.9809221316500.7247-100000@bright.fx.genx.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> caused the directory truncation race that your patch fixed, although
> admittedly this particular call to VOP_FSYNC() was added to support
> softupdates.  For another example, take a look at vinvalbuf(), which
> has the following code:
> 
> /*                          
>  * Flush out and invalidate all buffers associated with a vnode.
>  * Called with the underlying object locked.
>  */             
> int     
> vinvalbuf(vp, flags, cred, p, slpflag, slptimeo)
> [ snip ]
>                 if (vp->v_dirtyblkhd.lh_first != NULL) {
>                         splx(s);
>                         if ((error = VOP_FSYNC(vp, cred, MNT_WAIT, p)) != 0)
>                                 return (error);
>                         s = splbio();
>                         if (vp->v_numoutput > 0 ||
>                             vp->v_dirtyblkhd.lh_first != NULL)
>                                 panic("vinvalbuf: dirty bufs"); 
>                 }
>                 splx(s);
> 
> It sure looks to me like if VOP_FSYNC() called ffs_fsync(), ffs_fsync()
> would first write all the dirty buffers and then call softdep_fsync().
> Softdep_fsync() would unlock the vnode in order to sync the parent
> directories, and while the vnode was unlocked, another process could
> grab the vnode and dirty its buffers.  Softdep_fsync() would relock the
> vnode and return.  When VOP_FSYNC() returns, we get a nice panic ...

just to further my understand with a quite niave question :)
doesn't splx(s); block all other things from running thereby making this a
no-race situation?

(ducking and running back to language parsing)

-Alfred


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message