Date: Sat, 28 Feb 1998 15:54:10 +1100 From: Bruce Evans <bde@zeta.org.au> To: eivind@yes.no, jlemon@americantv.com Cc: fs@FreeBSD.ORG Subject: Re: syncer / SMP question Message-ID: <199802280454.PAA20951@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199802280454.PAA20951>