Date: Sun, 1 Mar 1998 00:49:43 +1100 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, eivind@yes.no, jlemon@americantv.com Cc: fs@FreeBSD.ORG Subject: Re: syncer / SMP question Message-ID: <199802281349.AAA03879@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>Are you saying the release of the mountlist lock on success normal?
Yes, whatever interlock is passed to lockmgr() is always released,
and for vfs_busy(), that lock is mountlist_slock.
>It looks very much abnormal to me; it is at the wrong layer. If this
>is normal, it means I'll have to remember 200 locking calls instead of
>5, as any call that mess with the locks must be considered a locking
>call. Ouch.
There aren't quite that many. vfs_busy() is apparently supposed to
simplify one common case.
>Now, here is what sync() would look like if I had free reign (I've cut
>the comment at the end here, for readbility):
>
>int
>sync(p, uap)
> struct proc *p;
> struct sync_args *uap;
>{
> struct mount *mp; /* mountpoint - walked through the list */
> struct mount *nmp; /* next-pointer (internal use in WALK_M_L) */
> int asyncflag;
>
> WALK_MOUNT_LIST(&mountlist, mp, nmp, p) {
> if ((mp->mnt_flag & MNT_RDONLY) == 0) {
> asyncflag = mp->mnt_flag & MNT_ASYNC;
> mp->mnt_flag &= ~MNT_ASYNC;
> vfs_msync(mp, MNT_NOWAIT);
> VFS_SYNC(mp, MNT_NOWAIT,
> p != NULL ? p->p_ucred : NOCRED, p);
> mp->mnt_flag |= asyncflag;
> }
> }
>}
>
>This is about half the code of the previous version, and to me it is
>much clearer than before.
It seems to make one case simpler. How would you handle a return from
inside the loop, like the one in getfsstat()? Requiring a single exit
point is not an option :-).
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?199802281349.AAA03879>