Date: Tue, 22 Sep 1998 17:58:05 -0700 From: Don Lewis <Don.Lewis@tsc.tdk.com> To: Alfred Perlstein <bright@hotjobs.com> Cc: current@FreeBSD.ORG Subject: Re: Yet another patch to try for softupdates panic Message-ID: <199809230058.RAA19571@salsa.gv.tsc.tdk.com> In-Reply-To: Alfred Perlstein <bright@hotjobs.com> "Re: Yet another patch to try for softupdates panic" (Sep 22, 1:20pm)
next in thread | previous in thread | raw e-mail | index | archive | help
On Sep 22, 1:20pm, Alfred Perlstein wrote:
} Subject: Re: Yet another patch to try for softupdates panic
} > 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);
} 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?
Nope, you've got it exactly backwards, splbio() blocks out interrupts at
the bio level and lower and splx(s) restores the previous interrupt mask.
We enter the above code with interrupts blocked, since we don't want
an interrupt handler mucking with vp->v_dirtyblkhd while we're looking
at it, then we unblock interrupts. After the VOP_FSYNC(), we block
interrupts again before doing the if test.
It wouldn't be desirable to block interrupts across the VOP_FSYNC() because
VOP_FSYNC() may take quite a long time. Actually, it would not even be
possible because VOP_FSYNC() does a bunch of disk I/O which needs the
interrupts that would be blocked by splbio().
Curiously enough, it is quite common for code to block interrupts and
then sleep to wait for an event. Somewhere down in the bowels of the
scheduler, the interrupts are then reenabled. The reason for doing this
is if you don't block interrupts, the event may be caused by an interrupt
that happens between the time you check to see if it safe for you to
continue and the time that you actually go to sleep and unless the event
happens again, you will never wake up ...
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?199809230058.RAA19571>