From owner-freebsd-current Sat Mar 14 01:53:40 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA11545 for freebsd-current-outgoing; Sat, 14 Mar 1998 01:53:40 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA11539 for ; Sat, 14 Mar 1998 01:53:33 -0800 (PST) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id CAA18199; Sat, 14 Mar 1998 02:53:33 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp01.primenet.com, id smtpd018182; Sat Mar 14 02:53:31 1998 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id CAA19801; Sat, 14 Mar 1998 02:53:27 -0700 (MST) From: Terry Lambert Message-Id: <199803140953.CAA19801@usr08.primenet.com> Subject: Re: 4 WILLRELE's to bite the dust To: michaelh@cet.co.jp (Michael Hancock) Date: Sat, 14 Mar 1998 09:53:27 +0000 (GMT) Cc: Tor.Egge@idi.ntnu.no, freebsd-current@FreeBSD.ORG In-Reply-To: from "Michael Hancock" at Mar 14, 98 02:37:10 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I've been using nullfs since Nov 7 1997 without any serious problems > > after having fixed some of the above mentioned problems in my local > > source tree. The code is not perfect, panics are still possible due > > to heuristics (due to VOP_ISLOCKED()) being wrong, but I've yet > > not experienced any problems. > > What would you need to do to fix VOP_ISLOCKED()? Does it really make > sense to have an VOP_ISLOCKED()? This ownership issue looks like a big > can of worms. Proxy the lock down with VOP_FINALVP. Alternately, put the locking in common upper level code, and assume it will be honored in the downpath, and move to veto-based VOP_LOCK. I prefer the veto method, because it buys you some nice wins in the fan-out/fan-in cases that would be difficult and costly to do otherwise. The vn_lock would assert the lock on the vp, and call the underlying VOP_LOCK on the vp, and if it was veto'ed, back it out. The coherency would be maintained by the stacking layer proxying the lock to the covered vnode (the downcall is needed in NULLFS only because it exposes the underlying FS multiple times in the namespace, so you must explicitly maintain choherency; things like union FS don't expose, so you could be sure that the underlying vp was locked, in effect, by the upper level vp being locked). The problem with the nullfs/nullfs mount (which *should* be permitted to work, since a -> nullfs -> nullfs -> otherfs stack is a perfectly reasonable thing to want to do so you can *avoid* exposing the stacked upon FS) is that the real VOP_LOCK occurs twice on the same vp because it's a real operation, not a proxy operation. There are other coherency problems having to do with the backing vp's associated VM object. John's recent changes allow aliases to work, so in theory, a finalvp is not necessary; the problem here is what gets marked dirty, however, so I have a hard time trusting anything that does aliases, even if John's code appeared to "do the right thing". My soloution would be to proxy the call to VOP_{GET|PUT}PAGES to the real underlying VP, via the bypass mechanism, and disallow aliases entirely. You could do the same thing with a VOP_FINALVP (which is useful for things other than locking, and not necessary in the veto implementation for locks; the advisory locks want to get hung off the object with the pages, and the vp's want to get locks if they get exposed anywhere in the namespace, but probably not otherwise (except in the allocation case, where they should be locked until they are pointed to by the covering layer, and the covering layer's vp should be locked, after which the covered layer can be unlocked (because it's ref'ed). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message