Date: Tue, 22 Sep 1998 13:20:11 -0500 (EST) From: Alfred Perlstein <bright@hotjobs.com> 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 Message-ID: <Pine.BSF.4.02A.9809221316500.7247-100000@bright.fx.genx.net> In-Reply-To: <199809221323.GAA17424@salsa.gv.tsc.tdk.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.02A.9809221316500.7247-100000>