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>