From owner-freebsd-fs  Fri Feb 27 20:56:10 1998
Return-Path: <owner-freebsd-fs@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id UAA20167
          for freebsd-fs-outgoing; Fri, 27 Feb 1998 20:56:10 -0800 (PST)
          (envelope-from owner-freebsd-fs@FreeBSD.ORG)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA20151
          for <fs@FreeBSD.ORG>; Fri, 27 Feb 1998 20:56:03 -0800 (PST)
          (envelope-from bde@godzilla.zeta.org.au)
Received: (from bde@localhost)
	by godzilla.zeta.org.au (8.8.7/8.8.7) id PAA20951;
	Sat, 28 Feb 1998 15:54:10 +1100
Date: Sat, 28 Feb 1998 15:54:10 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199802280454.PAA20951@godzilla.zeta.org.au>
To: eivind@yes.no, jlemon@americantv.com
Subject: Re: syncer / SMP question
Cc: fs@FreeBSD.ORG
Sender: owner-freebsd-fs@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

>> It appears to be released.  The vfs_busy() routine makes a call to
>> lockmgr(), which sets a lock on mountpoint and releases the lock on
>> the mountlist.
>
>But...  But...  What about the fetch of the next-pointer?  Looks like
>a potential race-condition to me, but this includes some lock-calls I
>don't really understand what do (interlocks?  What are they?).

Interlocks are for very short-term locks and for locking the aquisition
of full locks.

There is no race, because vfs_busy(), unlike lockmgr(), never releases
the interlock in the LK_NOWAIT case.  This non-release is surprising and
is actually commented on at the beginning of vfs_busy() (bug: the comment
says that the interlock is not released on failure, but it always
temporarily released on failure in the !LK_NOWAIT case).  Release of the
interlock on success is normal and is not commented on.

>Perhaps a WALK_MOUNTLIST macro would be better?  I use
>#define LIST_WALK_FORWARD(list, node, extra_node) \
>    for ((node) = (list)->pHead;              \
>        (node) = (extra_node);            \
>        (extra_node) = (node)->pNext)

No.  Macros are never better :-).  Here they would obfuscate the locking.

Bruce

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