Date: Tue, 10 Sep 2002 01:49:32 -0700 (PDT) From: Don Lewis <dl-freebsd@catspoiler.org> To: bde@zeta.org.au Cc: rwatson@FreeBSD.ORG, current@FreeBSD.ORG, jeff@FreeBSD.ORG Subject: Re: vnode lock assertion problem in nfs_link() Message-ID: <200209100849.g8A8nWwr094342@gw.catspoiler.org> In-Reply-To: <20020910182523.D367-100000@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10 Sep, Bruce Evans wrote: >> The locking changes in union_link() need a thorough review, >> though the light testing of that I performed didn't turn up any >> glaring problems. > > The changes are obviously just cleanups for leaf file systems, but I > wonder why everything wasn't always locked at the top. Could it have > been because locking all the way down is harmful? Judging by how the leaf filesystems were careful to only do the lock if tdvp != vp, I suspect there was the potential for a deadlock if both vnodes were automatically locked at the top. > The ugly gotos and uglier braces near them could be replaced by simple > returns now. Some related points: We can't change the gotos to returns unless we also make the change in (1). I think I agree with you about (1), but VN_KNOTE() doesn't have a man page and I didn't want to change anything that I didn't understand. I think (1) deserves a separate sweep and mega-commit. A quick look at ufs_vnops.c turns up a number of inconsistencies in the use of VN_KNOTE(). > (1) I think it is just a bug that null changes for failed operations are > knoted. It might be useful for knote to report attempted operations > and why they failed, but reporting failed operations doesn't seem > very useful unless they can be distinguished from successful ones. > Anyway, knote isn't told about failures before here. Doing the > knoting at a higher level upon successful completion would work > better in many cases including the above. This would be similar > to setting file times only upon successful completion, except it is > easier because knotes apply to vnodes but file times are fs-specific. > In both cases, it might be useful to set flags at lower levels in > some cases and back out the settings together with backing out the > main effects of the operation if the operation becomes unsuccessful > later. 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?200209100849.g8A8nWwr094342>