-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, March 10, 2003, at 08:26 AM, William Kucharski wrote:
In the last case [ if (ISSET(vp->v_flag, VUINIT)) ], where the
thread
sleeps waiting for the VNODE to finish init, the interlock is dropped
before waiting, but after returning from the wait it jumps immediately
to retry: w/o checking flags for LK_INTERLOCK. If LK_INTERLOCK is set,
then the interlock won't be acquired at the beginning of retry:. Maybe
I'm missing something, but before going to retry, shouldn't
LK_INTERLOCK be cleared or if set then then re-acquire the lock before
the jump?
What am I missing?
The first lines of the routine are:
retry:
/*
* If the vnode is in the process of being cleaned out for
* another use, we wait for the cleaning to finish and then
* return failure. Cleaning is determined by checking that
* the VXLOCK flag is set.
*/
if ((flags & LK_INTERLOCK) == 0)
simple_lock(&vp->v_interlock);
so when the VUINIT leg calls simple_unlock and sleeps, when it wakes
and
does a goto retry the lock will be reacquired if LK_INTERLOCK is still
0.
Right, but if the flag is set the VUINIT block still drops the interlock, and since that flag is set, it won't be re-acquired at the beginning of the loop. No lock == race condition or possible vnode corruption.
LK_INTERLOCK is not set by the simple_lock() call, or by any
intervening code
in vget(), so no flags are set that need to be unset; the release of
v_interlock is sufficient.
LK_INTERLOCK is set by the caller when they have already acquired the vnode interlock before calling vget. vget/vn_lock/others need to know this because they mess with the lock state. In this case, it looks like vget has a bug in its "messing" code. Brian Bergstrand <http://www.classicalguitar.net/brian/> PGP Key ID: 0xB6C7B6A2 All programmers are playwrights and all computers are lousy actors. - Unknown -----BEGIN PGP SIGNATURE----- Version: PGP 8.0 iQA/AwUBPmy5ennR2Fu2x7aiEQJLQwCfTx7Q94xIWmQM3UbqFn1veuQixiIAn0c4 FZT/UHdmCDnSVEw/t+UMCN6U =jAVC -----END PGP SIGNATURE----- _______________________________________________ darwin-kernel mailing list | darwin-kernel@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.